Access Control Policy

1. Purpose & Scope

This Access Control Policy (“Policy”) defines how DataChimp Labs grants, modifies, reviews, and revokes access to information systems, applications, data stores, and physical facilities. It exists to ensure that access to DataChimp Labs systems and data is authorized, appropriate to the role, and promptly removed when it is no longer required.

The Policy applies to:

All DataChimp Labs personnel — employees, contractors, and interns.
All information systems, applications, cloud environments, source repositories, identity providers, and administrative interfaces owned, leased, or operated by DataChimp Labs.
All non-human principals (service accounts, workloads, CI/CD runners, external integrations) that authenticate to DataChimp Labs systems.
All third parties granted access to DataChimp Labs systems or data under a written agreement.

This Policy supplements the Information Security Policy and should be read alongside it.

2. Policy Statement

DataChimp Labs enforces the principles of least privilege, need-to-know, and segregation of duties across all systems that process customer data or support the production platform. Access is:

Explicitly authorized — every entitlement traces to an approved business justification and a defined role.
Time-bound — standing access to production is minimized in favor of just-in-time, time-boxed elevations.
Auditable — every access grant, modification, and revocation is logged and reviewable.
Continuously validated — access is reviewed on a defined cadence and automatically de-provisioned when a role changes or ends.

This Policy is designed around a zero trust posture: no network location, device, or principal is trusted implicitly. Every request to a protected resource is authenticated, authorized, and evaluated in context before it is served.

3. Governance & Ownership

Role	Responsibility
Security Lead	Owns this Policy; owns the IAM control set; approves privileged-access exceptions.
Engineering Leadership	Implements RBAC in application and infrastructure code; owns service-to-service authentication design.
IT / People Operations	Owns joiner-mover-leaver (JML) workflow integration with the HRIS; drives on-time de-provisioning.
System Owners	Define the roles and entitlements for each system; participate in access reviews as reviewers of record.
All Personnel	Use only the access granted to them; report suspected credential compromise; complete required training.

4. Identity & Access Management (IAM) Architecture

DataChimp Labs operates a centralized identity and access management architecture. The corporate identity provider (IdP) is the single source of truth for workforce identity. Application, cloud, and administrative access is federated from the IdP wherever technically possible.

Key properties:

Single sign-on (SSO) — workforce access to SaaS applications, the AWS Organization, source control, CI/CD, observability, and internal administrative tools is federated through the corporate IdP using SAML or OpenID Connect.
Directory of record — the IdP is fed from the HRIS so that identity lifecycle events (hire, transfer, termination) propagate automatically.
Local accounts prohibited — local accounts on individual systems and standing IAM users are prohibited except for narrowly scoped, documented break-glass use with credentials stored in a secured vault.
Grouping — access is granted to IdP groups, not individuals, and group membership is derived from role assignments in the HRIS where feasible.

5. Zero Trust Access Architecture

DataChimp Labs implements a zero trust access architecture for access to production systems and sensitive corporate resources:

No implicit network trust. Internal networks are not treated as safe. Access decisions do not rely on VPN presence or IP location as sole factors.
Strong identity per request. Every request to a protected resource is authenticated with a strong, phishing-resistant credential for human access and a short-lived, scoped credential for non-human access.
Device posture. Workforce access to production consoles and sensitive data is conditioned on live device-compliance signals from the endpoint management platform: managed device enrollment, full-disk encryption on, current OS patch level, endpoint detection and response (EDR) agent installed and healthy, and screen lock enabled. Devices that fail any of these signals are blocked from production access until posture is restored.
Continuous evaluation. Session risk is re-evaluated during the session; anomalous behavior (impossible travel, sudden privilege use, new device) triggers step-up authentication or session termination.
Micro-segmentation. Production workloads run in isolated AWS sub-accounts and private VPCs; egress and inter-service communication are constrained by policy rather than network reachability.

6. Role-Based Access Control (RBAC)

Access to DataChimp Labs systems is granted through role-based access control. Roles are defined in infrastructure-as-code and application configuration and are reviewed for excess privilege on every change.

Role catalog. Each system defines a documented set of roles (for example: read-only analyst, engineer, service operator, IAM administrator, security auditor). Each role is mapped to a specific set of entitlements.
Role assignment. Personnel are assigned to roles based on their job function, not on individual requests for entitlements. New roles require design review and approval by the system owner and the Security Lead.
Segregation of duties. Sensitive combinations of entitlements (for example, the ability to both approve and deploy a change to production) are separated between distinct roles. Where a single role must combine such entitlements for operational reasons, a compensating control (independent review, out-of-band logging) is documented. Any such combination requires written approval from the Security Lead, is documented as a compensating control in the access review record, and is re-evaluated at every quarterly access review.
Attribute-based refinement. Where RBAC alone is insufficient, roles are refined with attribute-based conditions (for example, region, environment, data classification, time-of-day) enforced at the policy layer.

7. Authentication for Non-Human Principals

Non-human access — service-to-service calls, workloads, CI/CD runners, external integrations, and scheduled jobs — uses strong, verifiable credentials. Long-lived, embedded secrets are avoided by policy.

Approved patterns:

OAuth 2.0 tokens for third-party API integrations and delegated access, with scoped grants, short lifetimes, and refresh tokens stored in a managed secret store.
Workload identity federation for CI/CD (for example, GitHub Actions OIDC to AWS IAM roles) so that pipeline runs receive short-lived, scoped credentials without long-lived cloud access keys.
IAM roles for workloads (EC2 instance roles, Lambda execution roles, ECS task roles, EKS pod identity) providing short-lived, rotating credentials to production compute.
TLS client certificates issued from an internal certificate authority for service-to-service authentication where mutual TLS is used.
Signed requests (for example, AWS SigV4) for cloud API calls.

Where a long-lived credential is unavoidable, it is stored in AWS Secrets Manager or SSM Parameter Store SecureString, restricted by IAM policy, rotated on a defined schedule, and inventoried.

8. Privileged Access

Privileged access — production administrator, root, IAM administrator, security tooling administrator, database administrator — is treated as a high-risk entitlement:

Minimized standing access. Standing privileged access is limited to the smallest set of personnel operationally required and is documented in the role catalog.
Just-in-time elevation. Where feasible, privileged access is granted just-in-time through an approval workflow that produces an auditable record and a time-boxed session.
Multi-factor authentication. Phishing-resistant multi-factor authentication is required for all privileged access.
Break-glass. Break-glass accounts are documented, monitored, and reviewed after every use.
Monthly review. Privileged access is reviewed monthly (see Section 10).

9. Joiner, Mover, Leaver — Automated Lifecycle

DataChimp Labs operates an automated joiner-mover-leaver (JML) workflow integrated with the HRIS and the IdP:

Joiner. On confirmed hire, the HRIS creates an identity in the IdP, assigns the role appropriate to the position, and provisions role-based access to downstream systems through SSO group membership.
Mover. On role change or transfer, the HRIS updates role assignment, which propagates through the IdP; previous entitlements no longer associated with the new role are removed. Managers confirm the change within one business day.
Leaver. On termination or end of engagement, the HRIS triggers an automated de-provisioning workflow that:
- Disables the IdP account, terminating active SSO sessions across downstream applications.
- Revokes SaaS access, source control access, cloud access, VPN access, and administrative console access.
- Rotates or revokes any long-lived credentials the individual held (API keys, service account owners, code signing keys).
- Reclaims the workforce endpoint through the endpoint management platform.
Timeliness. Access removal for terminated personnel occurs on the effective date, and no later than one business day. Involuntary terminations trigger immediate revocation coordinated between People Operations and Security.
Evidence. Every JML event produces an auditable record retained for the period defined in the retention schedule.

10. Periodic Access Reviews & Audits

Access is validated on a defined cadence, not only at the point of grant:

Quarterly reviews. Access to production systems, source control, cloud consoles, sensitive data stores, and administrative interfaces is reviewed quarterly. The Security Lead owns the review process and system owners certify that each identity’s entitlements remain appropriate for the current role. Completed review artifacts (reviewer, reviewee, entitlement, decision, timestamp) are retained under evidence/ in this repository for audit.
Monthly privileged review. Privileged access is reviewed monthly.
Annual comprehensive review. A comprehensive review of the entire role catalog, entitlement definitions, and IdP group memberships is performed at least annually.
Trigger-based reviews. Reviews are additionally triggered on material events: reorganization, incident, framework audit, or material change to a system’s data classification.
Findings. Excess entitlements identified during review are removed within the remediation SLA for the affected system’s data classification. Findings and their remediation are tracked in the corrective action register.
Evidence. Every review produces an auditable record (reviewer, reviewee, entitlement, decision, timestamp) retained per the retention schedule.

11. Access Logging & Monitoring

Authentication events (successes, failures, MFA challenges, step-up), authorization decisions, and privileged actions are logged to a centralized, access-controlled log store.
High-signal detections — anomalous privilege use, impossible travel, brute-force patterns, service credential misuse — generate alerts routed to on-call engineers.
Logs are retained for the period defined in the retention schedule and are protected against tampering.

12. Third-Party & Contractor Access

Third parties are granted access only under a written agreement that includes confidentiality, security, and, where required, data processing terms.
Third parties receive individual, named accounts federated through the IdP where feasible; shared credentials are prohibited.
Third-party access is time-bound and reviewed at least quarterly along with workforce access. Termination of the underlying agreement triggers the leaver workflow.

13. Review Cadence

This Policy is reviewed by the Security Lead at least annually and whenever there is a material change to the identity provider, the IAM architecture, the platform, the regulatory landscape, or the organization. The next scheduled review date is recorded in the front-matter of this document.

14. Enforcement

Compliance with this Policy is a condition of employment or engagement with DataChimp Labs. Attempted circumvention of access controls, sharing of credentials, or unauthorized privilege escalation may result in disciplinary action up to and including termination, and, where appropriate, referral to law enforcement.

15. Approval & Version History

Version	Date	Author	Change
1.0	2026-09-01	DataChimp Labs — Security	Initial issue of the Access Control Policy.

Approved by: CTO, DataChimp Labs (signature on file with the Security Lead).

Contact. Security questions about this Policy should be directed to security@datachimplabs.com. Postal correspondence: DataChimp Labs, 4507 N 189th St, Elkhorn, NE 68022, USA.