Skip to main content

accessVersion 1SOC2ISO27001NIST800-171

Access Control Policy

How logical access to systems and data is granted, reviewed, modified, and revoked.

Download PDFSHA-256 9011825f05d06bca…

Access Control Policy

1. Purpose

Defines how Rex Black provisions, reviews, modifies, and revokes logical access to its systems and data.

2. Scope

All Rex Black systems, AWS accounts, SaaS tools, code repositories, databases, and any client system Rex Black personnel are authorized to access.

3. Policy statements

3.1 Identity

  1. Every human user has a single, named identity tied to a @rexblack.com Google Workspace account. Shared accounts are prohibited.
  2. Service-to-service access uses named IAM roles or API keys scoped to a specific workload. API keys are stored only in AWS SSM Parameter Store (SecureString) or the Rex Black Vault; never in source code.

3.2 Authentication

  1. Multi-factor authentication (MFA) is required for every @rexblack.com identity on:
    • Google Workspace
    • AWS (IAM Identity Center / SSO)
    • GitHub
    • Rex Black Admin surface (/admin/*)
    • Any SaaS handling client data
  2. Passwords shall conform to the Password Policy (013-password-policy.md).
  3. Session inactivity timeout on the Admin surface is 8 hours; session absolute lifetime is 24 hours.

3.3 Authorization

  1. Access is granted on the principle of least privilege. Users start with zero access and receive only the roles their job requires.
  2. Rex Black Admin uses Role-Based Access Control (RBAC) with the following roles: owner, admin, pm, developer, sales, support, viewer. The authoritative mapping of role → capability is in registers/access-control-matrix.md.
  3. Elevated access (production AWS write, vault break-glass, cross-tenant read) requires documented business justification and is time-boxed.

3.4 Provisioning & deprovisioning

  1. On hire, access is provisioned by the Security Officer from a written role template and logged in the audit log.
  2. On role change, access is reviewed within 5 business days by the Security Officer.
  3. On termination:
    • Google Workspace account is suspended within 1 business hour.
    • All SaaS sessions are revoked within the same 1 business hour.
    • All long-lived API tokens owned by the user are rotated within 24 business hours.
    • Vault items of which the user was the sole owner are rekeyed to the Security Officer within 24 business hours.

3.5 Access reviews

  1. The Security Officer conducts a quarterly access review. Evidence (who has what role, delta since last review, approvals) is exported from the Admin surface and filed in the Rex Black Vault under compliance/access-reviews/.
  2. Every review is signed by the CEO.

3.6 Client data access

  1. Rex Black personnel shall access a client's data only in the execution of an engagement the client has signed for.
  2. Every client-data read and write is recorded in the audit log with resourceOrgId populated. Cross-tenant queries by engineers require an approved, time-boxed elevation.

4. Roles & responsibilities

Role Responsibility
Security Officer Provisioning, deprovisioning, quarterly review, exceptions.
CEO Signs quarterly access reviews.
All personnel Do not share credentials; report suspected access abuse.

5. Enforcement & exceptions

Credential sharing is grounds for immediate access revocation. Exceptions require an approved, time-boxed entry in the Risk Register.

6. References

  • 013-password-policy.md
  • 008-cryptography-and-key-management-policy.md
  • registers/access-control-matrix.md
  • registers/incident-response-runbook.md

7. Revision history

Version Date Author Approver Change
1.0 2026-04-17 S.O. CEO Initial policy

Approval

This policy has been reviewed and is hereby approved for the named version and effective date above.

Approved by Myles Bai
Title Chief Executive Officer, Rex Black LLC
Email myles@rexblack.com
Approval date 2026-04-17
Effective date 2026-04-17
Next review due 2027-04-17

Digital signature of record: the CEO's electronic approval is captured in the platform audit log (event kind admin.policy.approved) with hash-chained integrity under the M-C1 control. The hash-chained audit log entry for this document is the canonical signature of record; this printed block exists for print/review convenience.

← Back to the trust center