Compliance
Granting access this way actively helps your compliance posture. Here is how it maps to the frameworks your auditors care about.
The control mappings below apply across AWS, GCP, and Azure; where the exact mechanism differs per cloud (audit log service, session model), it's called out inline. AWS currently has the deepest evidence tooling (a dedicated dashboard, see monitoring); GCP and Azure rely on their own native audit logs directly, which still satisfy the underlying control, just without a CE-built dashboard yet.
SOC 2
CC6 - Logical and Physical Access Controls
| Criteria | Requirement | How this satisfies it |
|---|---|---|
| CC6.1 | Logical access security measures | Roles are scoped by least privilege. Each CE role grants only what is needed. |
| CC6.2 | Prior to issuing credentials | No standing credentials are issued to you. Access is federated from CE's own identity provider, with MFA enforced there. |
| CC6.3 | Role-based access | CE-ReadOnly, CE-SRE, CE-DevOps, CE-Admin, etc. are distinct roles with defined scopes on every cloud. |
| CC6.6 | Logical access restricted to authorized users | Enforced technically, not by policy: AWS requires an ExternalId on every role assumption, GCP scopes access to a specific federated provider per tier, Azure grants access only via an explicit per-engineer guest invitation. |
| CC6.8 | Controls to prevent unauthorized access | AWS/GCP: short-lived tokens (2-4h), no standing access. Azure: access is a direct, named role assignment you can revoke with one command. |
CC7 - System Operations
| Criteria | Requirement | How this satisfies it |
|---|---|---|
| CC7.2 | Monitor system components | Every action by a CE role appears in your cloud's own audit log under the engineer's identity: CloudTrail (AWS), Cloud Audit Logs (GCP), Activity Log (Azure). |
| CC7.3 | Evaluate security events | AWS: CE-Admin assumption triggers a real-time email alert to your security team. GCP/Azure: admin-tier activity is visible in your native audit log; dedicated alerting is on the roadmap. |
CC9 - Risk Mitigation
| Criteria | Requirement | How this satisfies it |
|---|---|---|
| CC9.2 | Vendor and business partner risk | Access is scoped, auditable, time-limited or individually revocable, and removable with one command per cloud (see Security Model). |
Evidence for auditors: the deploy artifact for your cloud (CloudFormation template / gcp-deploy.sh / azure-deploy.sh), the resulting role/permission grants, and your cloud's own audit log together constitute evidence of CC6 and CC9.2 compliance. Export the deploy artifact plus 90 days of your audit log as your evidence package.
ISO 27001:2022
A.8 - Technological Controls
| Control | Requirement | How this satisfies it |
|---|---|---|
| A.8.2 | Privileged access rights | CE-Admin carries the shortest session (AWS/GCP) or is individually named and revocable (Azure), and triggers an alert on assumption where alerting is built (AWS today). |
| A.8.5 | Secure authentication | MFA enforced at CE's own identity provider, a technical control every engineer must pass before any session exists, not a policy someone could skip. |
| A.8.15 | Logging | Your cloud's own audit log (CloudTrail / Cloud Audit Logs / Activity Log) provides immutable logs of all activity by CE engineers. |
| A.8.18 | Use of privileged utility programs | No SSH daemon needs to be exposed on any cloud: AWS uses Systems Manager, GCP uses IAP tunneling, Azure uses Bastion. |
A.5 - Organizational Controls
| Control | Requirement | How this satisfies it |
|---|---|---|
| A.5.19 | Information security in supplier relationships | Access is scoped, auditable, and revocable on every cloud. CE cannot access resources outside the roles granted. |
| A.5.20 | Addressing security within supplier agreements | The deployed role/permission grant is the technical enforcement of the supplier agreement, not just a document. |
HIPAA
For environments handling PHI (45 CFR Part 164):
Technical Safeguards (164.312)
| Safeguard | Requirement | How this satisfies it |
|---|---|---|
| 164.312(a)(2)(i) | Unique user identification | Every CE engineer has a unique identity. Your audit log shows their individual identity, not a shared account. |
| 164.312(a)(2)(iii) | Automatic logoff | AWS/GCP: session tokens expire automatically in 2-4 hours with no extension. Azure: access is revoked directly, on demand. |
| 164.312(b) | Audit controls | Your cloud's own audit log provides the mechanisms to record CE activity. |
| 164.312(d) | Person or entity authentication | MFA enforced at CE's own identity provider before any session can exist. |
BAA
If CE engineers may encounter PHI during the engagement, ensure a Business Associate Agreement is in place with continuous.engineering before granting access. Contact hello@continuous.engineering.
PCI DSS v4.0
Requirement 7 - Restrict Access
| Requirement | How this satisfies it |
|---|---|
| 7.2 - Access control system | IAM roles / RBAC role assignments are the access control system on every cloud. Deny-by-default. |
| 7.2.4 - Review of user accounts | Access is reviewed by re-running the deploy step (AWS/GCP) or re-running the roster sync (Azure). No dormant accounts accumulate. |
Requirement 8 - Authenticate Access
| Requirement | How this satisfies it |
|---|---|
| 8.2 - Unique IDs | Every CE engineer has a unique identity. No shared accounts on any cloud. |
| 8.3 - Strong authentication | MFA enforced at CE's own identity provider before any session can exist. |
Requirement 10 - Log and Monitor
| Requirement | How this satisfies it |
|---|---|
| 10.2 - Audit log implementation | Your cloud's own audit log captures all activity including role assumptions/assignments, with timestamps and source identity. |
| 10.3 - Audit log protection | Audit logs are written and protected by your cloud provider's own log storage. CE roles have no ability to delete log files. |
ISO 42001 (AI Management)
If CE is engaged for AI or ML work:
| Control | How this satisfies it |
|---|---|
| 6.1 - Risk assessment | Access to AI training data is scoped via CE-Data to explicitly tagged/scoped resources only. |
| 8.4 - Data governance | CE engineers can only access data resources you have explicitly tagged and granted. |
| 9.1 - Monitoring | Your cloud's own audit log provides a full record of all data access during the engagement. |
Evidence package for auditors
| Evidence | Where to find it |
|---|---|
| What roles/permissions were created and what they can do | Deploy artifact for your cloud (CloudFormation template / gcp-deploy.sh / azure-deploy.sh, all in this repo) |
| Every action taken by CE engineers | Your cloud's own audit log (CloudTrail / Cloud Audit Logs / Activity Log) |
| MFA and access-control enforcement | CE's own identity provider policy (available on request) plus your cloud's role/trust definitions |
| Access revocation | The removal command's output, or your cloud's own change history for the resource |
All of this lives in your own account, project, or subscription. You own it. We cannot modify or delete it.