Access Control Policy¶

1. Purpose¶

This policy establishes the requirements for requesting, approving, provisioning, reviewing, modifying, and revoking access to ClaraRx's systems, applications, infrastructure, and data.

The objectives of this policy are to:

Ensure access is granted only to authorized individuals with a legitimate business need.
Enforce the principle of least privilege.
Establish accountability for access-related decisions and changes.
Maintain accurate records of user access and associated approvals.
Ensure access is reviewed periodically and revoked when no longer required.
Support ClaraRx's security and compliance obligations, including SOC 2.

2. Scope¶

This policy applies to all employees, contractors, and other individuals authorized to access ClaraRx systems or data.

It covers company-managed systems and services, including but not limited to:

Google Workspace
GitHub
AWS
Fly.io
Cloudflare
Xata
Infisical
Sentry
Linear
Monitoring, logging, and security platforms
Other systems that store, process, or provide access to company or customer information

This policy also applies to privileged accounts, service accounts, API tokens, deployment credentials, and other non-human identities that provide access to company resources.

3. Roles and Responsibilities¶

3.1 Employees and Contractors¶

Employees and contractors must:

Request access through the access request process.
Provide a valid business justification for requested permissions.
Use company accounts and approved authentication methods.
Protect credentials and authentication factors from unauthorized disclosure.
Use granted permissions only for authorized business purposes.
Notify their manager or DevOps when access is no longer required.
Report suspected unauthorized access or compromised credentials promptly.

Individuals must not grant access to other users unless explicitly authorized to do so.

3.2 Engineering Leads and Authorized Approvers¶

Engineering Leads or designated system owners are responsible for:

Evaluating access requests against business requirements.
Confirming that requested permissions are appropriate for the individual's role.
Approving or rejecting access requests before provisioning.
Authorizing privileged access and documented exceptions within their authority.
Participating in periodic access reviews.
Initiating access changes when responsibilities change or access is no longer required.

Approvers must consider whether a less privileged permission level would satisfy the stated business need.

3.3 DevOps Engineer¶

The DevOps Engineer is responsible for:

Maintaining the Access Management Register.
Maintaining the Role-Based Access Control (RBAC) Matrix in coordination with Engineering Leads.
Verifying that required approvals are documented before granting access.
Provisioning, modifying, and revoking access in accordance with approved requests.
Maintaining access-request and change records in Linear.
Coordinating periodic access reviews and reconciling records against actual system configurations.
Maintaining access-management procedures and supporting audit evidence.
Identifying and reporting unauthorized access, excessive permissions, and discrepancies.
Ensuring that privileged access is appropriately restricted and reviewed.

The DevOps Engineer must not independently approve their own access requests. Such requests must be approved by an authorized individual who is independent of the request.

3.4 System Owners¶

Designated system owners are responsible for:

Identifying appropriate permission levels for their systems.
Defining or validating role-based access requirements.
Participating in access reviews for systems under their responsibility.
Confirming whether users continue to require their assigned permissions.
Supporting the investigation and remediation of access discrepancies.

System owners may be Engineering Leads, DevOps, or other individuals formally authorized to fulfill this responsibility.

4. Access Management Principles¶

All access to ClaraRx systems must follow these principles.

4.1 Least Privilege¶

Users must receive only the permissions necessary to perform their assigned responsibilities. Administrative and production-level permissions must not be granted by default when lower-privilege access is sufficient.

4.2 Role-Based Access Control¶

Where supported, access should be assigned through predefined roles and permission groups rather than individually assembled permissions.

The RBAC Matrix defines the expected access levels for each role and serves as the reference for evaluating access requests. Exceptions to the RBAC Matrix must have a documented business justification and explicit approval.

4.3 Individual Accountability¶

Users must access company systems through individually attributable accounts wherever supported.

Shared user accounts should be avoided. Where a shared or non-personal account is necessary, its purpose, owner, authorized users, and credential-management arrangements must be documented.

4.4 Authentication and Credential Security¶

Multi-factor authentication (MFA) must be enabled for company systems that support and require it under ClaraRx's authentication requirements.

Privileged access must use the strongest supported authentication controls appropriate to the system.

Passwords, API keys, access tokens, and other secrets must be stored in approved secret-management systems. They must not be stored in the Access Management Register or ordinary documentation.

4.5 Separation of Duties¶

Where practical, access requesting, approval, provisioning, and independent review should be performed by different individuals.

Where organizational size or operational requirements prevent complete separation, an appropriate independent review or other documented compensating control must be used.

5. Access Management Records¶

ClaraRx maintains centralized access-management records to document approved access and support periodic reviews.

5.1 Access Management Register¶

The Access Management Register is maintained in a company-owned Google Workspace Shared Drive with access restricted to authorized personnel.

The register must identify, as applicable:

User name and company email address.
System and account or resource.
Assigned role and permission level.
Access classification, including privileged or temporary access.
Business justification.
Associated access-request ticket.
Approver and approval date.
Individual responsible for provisioning.
Actual provisioning date.
Relevant review date and review outcome.
Access status.
Actual revocation date, where applicable.

The register must reflect actual assigned permissions rather than only requested or intended access. The DevOps Engineer is responsible for keeping the register current following access changes.

5.2 RBAC Matrix¶

The RBAC Matrix defines the expected permissions associated with organizational roles.

It must identify the systems each role may access, the permitted permission levels, and any additional approval requirements for privileged or production access.

The matrix must be reviewed periodically and updated when roles, systems, or business requirements change.

5.3 Authoritative Access Records¶

Actual system configurations are the authoritative source for determining who currently has access to a particular system.

The Access Management Register provides a consolidated record and must be reconciled against these configurations during access reviews.

Access requests, approvals, provisioning records, revocation records, and remediation activities must be documented in Linear.

Supporting evidence, including access-review records and relevant system exports, must be retained in an appropriately restricted company-controlled location.

Vanta may be used to monitor applicable compliance controls and track supporting evidence.

6. Exceptions and Policy Violations¶

Exceptions to this policy must have a documented business justification, an identified owner, an authorized approver, and an appropriate review or expiry date. Exceptions must be limited to the minimum necessary scope and duration.

Unauthorized access, missing approvals, excessive permissions, and other material discrepancies must be investigated and remediated.

The DevOps Engineer must document the issue, create a remediation ticket where appropriate, and retain evidence of the corrective action.

Historical records must not be altered to imply that an approval, review, or access change occurred earlier than it actually did.

7. Evidence Retention and Audit Support¶

Access-management evidence must be retained in accordance with ClaraRx's applicable information-retention requirements and compliance obligations.

Relevant evidence includes:

Access requests and approvals.
Provisioning and revocation records.
The Access Management Register.
The RBAC Matrix.
Periodic access-review records.
System access exports or equivalent records.
Documented exceptions and remediation tickets.
Evidence of policy reviews and material changes.

Access to these records must be restricted to authorized personnel.

When evidence is provided to an auditor, only the information relevant to the audit request should be shared, using an approved and appropriately restricted channel.

8. Policy Review and Maintenance¶

The DevOps Engineer is responsible for maintaining this policy in the company's version-controlled GitHub documentation repository.

Engineering Leads or other authorized policy owners must review and approve material changes.

This policy must be reviewed at least annually and whenever material changes to systems, organizational responsibilities, security requirements, or access-management processes occur.

Updates must be recorded through the repository's version-control and review process.

9. Policy Compliance¶

All individuals within the scope of this policy must comply with its requirements.

Non-compliance must be reported to the appropriate Engineering Lead or designated company authority and addressed according to ClaraRx's established procedures.

Failure to follow access-management requirements may result in access restrictions or other appropriate corrective action.

Document Control¶

Field	Value
Document Title	Access Control and Access Management Policy
Document Owner	DevOps
Approving Authority	Authorized Engineering Lead or designated policy owner
Version	1.0
Status	Draft — Pending Approval
Effective Date	To be assigned upon approval
Review Frequency	At least annually
Primary Operational Record	Access Management Register in Google Workspace Shared Drive
Access Request and Approval System	Linear
Policy Repository	Company GitHub documentation repository
Compliance Monitoring	Vanta, where applicable