> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access control policy

> Annex A.5.15–5.18, A.8.2–8.5 — formal policy governing how access to Denialbase systems and data is granted, reviewed, and revoked.

<Info>
  This policy operates alongside [Authentication](/trust/authentication) (how we verify identity). This page covers authorization — **who gets access to what, for how long, and how we verify it stays correct**.
</Info>

**Owner**: Security Officer · **Implementation owner**: CTO · **Policy version**: 0.9 (draft)

## Principles

<CardGroup cols={2}>
  <Card title="Least privilege" icon="minimize">
    Every identity gets the minimum permissions needed to perform its role. Permissions are additive and opt-in, not stripped-down from a broad default.
  </Card>

  <Card title="Role-based" icon="users">
    Permissions attach to roles, not individuals. Individuals inherit permissions via role assignment.
  </Card>

  <Card title="Separation of duties" icon="scale-balanced">
    Critical operations require two independent actors (e.g. deploy + approval; policy change + security officer sign-off).
  </Card>

  <Card title="Periodic review" icon="rotate">
    Access isn't fire-and-forget. Every access grant is reviewed on a defined cadence; unused grants are revoked.
  </Card>

  <Card title="Just-in-time for privileged access" icon="clock">
    Privileged operations (prod database read, secret rotation) use time-limited elevation rather than persistent grants.
  </Card>

  <Card title="Audit by default" icon="clipboard-list">
    Every grant, revocation, and use of privileged access is audit-logged for 7 years.
  </Card>
</CardGroup>

## Identity types

| Identity type                 | Examples                                | How it authenticates                                                                                              |
| ----------------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **Customer user**             | Billing staff, provider, practice admin | Password + 2FA (TOTP/passkey), OAuth, or SAML SSO                                                                 |
| **Denialbase workforce**      | Employee, contractor                    | SSO via Google Workspace + enforced 2FA                                                                           |
| **Service account (runtime)** | Cloud Run backend, worker VM            | GCP IAM binding + Workload Identity (no long-lived keys)                                                          |
| **CI/CD identity**            | GitHub Actions deploy workflows         | Workload Identity Federation (short-lived OIDC → GCP token exchange)                                              |
| **API token**                 | Server-to-server integrations           | Scoped, revocable, time-bound token (see [Authentication — API tokens](/api-reference/authentication#api-tokens)) |

## Customer-side access control

<AccordionGroup>
  <Accordion title="Roles">
    Five roles (see [Admins — team management](/admins/team-management)):

    | Role                                | PHI access                       |
    | ----------------------------------- | -------------------------------- |
    | `user`                              | Own work, within assigned queues |
    | `analyst`                           | Aggregated/anonymized only       |
    | `support`                           | Read-only, scoped                |
    | `admin`                             | Full within org, no delete       |
    | (Denialbase internal) `super_admin` | Full platform, heavily audited   |
  </Accordion>

  <Accordion title="Policy enforcement">
    Every API action is authorized by a Pundit policy (48 policy files as of April 2026). `ApplicationController` enforces `after_action :verify_authorized` globally — any action that doesn't authorize or skip raises.
  </Accordion>

  <Accordion title="Tenancy isolation">
    Every PHI-bearing row carries an `organization_id`. Pundit policies scope queries to the caller's organization by default. Cross-tenant access requires an explicit super-admin policy and is audit-logged.
  </Accordion>

  <Accordion title="Session controls">
    30-minute idle timeout; 24-hour maximum session. Configurable per org.
  </Accordion>
</AccordionGroup>

## Workforce-side access control

### Standard access

Granted on hire based on role. Reviewed quarterly.

| System            | Role-based defaults                                |
| ----------------- | -------------------------------------------------- |
| GitHub            | Developers: write to denialbase repo; others: none |
| Google Workspace  | Email, Drive, Calendar for all                     |
| GCP (staging)     | Developers: view; operations: write                |
| GCP (production)  | No direct access by default; just-in-time only     |
| 1Password         | Shared vaults by role                              |
| Sentry            | Engineering: access to error events                |
| Customer admin UI | Support + ops: read-only, scoped, ticketed         |

### Privileged access

Production data access is **just-in-time**:

<Steps>
  <Step title="Request">
    Engineer or operator opens a break-glass request with: reason, ticket link, scope (what data), duration (≤ 4 hours by default).
  </Step>

  <Step title="Approve">
    Approver (CTO or Security Officer) reviews. Approval is logged.
  </Step>

  <Step title="Elevate">
    IAM binding is created with a time-limited expiry.
  </Step>

  <Step title="Use">
    All actions in the elevated session are audit-logged with the break-glass ticket reference.
  </Step>

  <Step title="Expire">
    IAM binding auto-expires. Post-action summary filed within 24 hours.
  </Step>
</Steps>

Sev-1 incidents may trigger emergency elevation; all emergency uses are reviewed in the subsequent [incident post-mortem](/trust/incident-response) and [management review](/trust/management-review).

### Segregation of duties (A.5.3)

| Activity                   | Separated                                                                |
| -------------------------- | ------------------------------------------------------------------------ |
| Deploy code to prod        | CI/CD pipeline (not any individual engineer)                             |
| Approve a PR               | Author ≠ reviewer                                                        |
| Change an Annex A control  | Security Officer + one other executive                                   |
| Rotate encryption keys     | CTO proposes + Security Officer approves + independent reviewer verifies |
| Modify audit log retention | Security Officer + CTO; any change audit-logged in a higher-tier log     |

## Service account access control

* **Minimum privilege per service account** — Cloud Run runtime SA has access only to the secrets and resources it needs at runtime.
* **No long-lived keys** — Workload Identity Federation for CI/CD, Workload Identity (in-cluster) for service-to-service.
* **Annual review** of service account IAM bindings as part of internal audit.
* **Automatic revocation** of unused service accounts (90-day idle threshold).

## Access review (A.5.18)

<Info>
  Quarterly access reviews are a top audit focus. We don't skip them.
</Info>

| Review type                                              | Frequency                               | Who performs                     | Artifact                         |
| -------------------------------------------------------- | --------------------------------------- | -------------------------------- | -------------------------------- |
| **Standard user access**                                 | Quarterly                               | Engineering manager (per report) | Signed review record             |
| **Privileged access**                                    | Monthly                                 | Security Officer                 | Review record                    |
| **Service account IAM**                                  | Quarterly                               | CTO                              | Review record                    |
| **Customer-admin UI grants (support)**                   | Quarterly                               | Head of Support                  | Review record                    |
| **Third-party tool grants (Sentry, Slack, GitHub orgs)** | Quarterly                               | Security Officer                 | Review record                    |
| **Post-offboarding**                                     | Within 1 business day of termination    | Security Officer                 | Confirmation logged in HR record |
| **Post-role-change**                                     | Within 1 business day of effective date | Security Officer                 | Confirmation logged in HR record |

Unused grants are revoked in the review; exceptions require documented business justification with an expiry.

## Password and credential hygiene

* Passwords must meet the complexity rules defined in the [AUP](/trust/acceptable-use-policy#account-security).
* 1Password is provided and required — no reuse, no local storage in plaintext.
* MFA required on every account with production-adjacent access.
* No shared credentials for any system (exceptions documented).

## Emergency / break-glass access

For production incidents:

* A pre-approved break-glass role exists that grants broad access for a 4-hour window.
* Granted by the Security Officer (or CTO if SO unreachable).
* Use is written up within 24 hours in the incident post-mortem.
* Reviewed at the next [management review](/trust/management-review).

## Failure to comply

* First-time minor violations: retraining.
* Repeat or material violations: discipline per [AUP enforcement](/trust/acceptable-use-policy#enforcement).
* Willful breaches involving PHI: termination + referral as required by law.

## Related

* [Authentication](/trust/authentication) — the "how we verify identity" companion
* [HR security](/trust/hr-security) — onboarding/offboarding tied to access changes
* [Audit logging](/trust/audit-logging) — the record of who did what, when