3AM compliance: how the architecture maps to audit and regulatory requirements

3AM's audit log lives in your AWS account, uses S3 Object Lock in compliance mode (no principal — including AxelSpire and AWS root — can modify or delete receipts before their retention date), and supports customer-controlled retention from 1 to 100 years (default 7). The architectural properties map directly to SEC 17a-4(f), FINRA 4511(c), PCI DSS 4.0, SOC 2, the HIPAA Security Rule, and DORA. 3AM provides the architecture; the certification stays with you.

This page covers 3AM's compliance posture and how it maps to specific frameworks. For why 3AM exists and the broader case for control-plane PKI, see 3AM control plane. For the vendor access model and onboarding mechanics, see 3AM deployment.

What "compliance" means architecturally for 3AM

Three architectural properties determine what an auditor will actually see when reviewing 3AM:

• The audit log lives in your account. It is an S3 bucket in the customer's AWS account, not in AxelSpire's. Auditors review evidence in your environment, against your IAM, your CloudTrail, your encryption keys, your retention policy. The audit boundary is the boundary of your account — there is no vendor-side log to request and no vendor-side rate limit on export.
• The log cannot be modified. S3 Object Lock compliance mode prevents any principal — AxelSpire, your own break-glass roles, AWS Support, the AWS root user — from modifying or deleting a receipt before its retention date. AWS publishes a Cohasset Associates assessment recognising Object Lock compliance mode for SEC 17a-4(f), FINRA 4511(c), and CFTC 1.31 broker-dealer recordkeeping.
• Retention is customer-controlled. Default 7 years, configurable from 1 to 100 years at deployment. Can be increased after the fact (legal hold); cannot be reduced for objects already written.

These properties are independent of AxelSpire's own corporate certifications. Whether or not AxelSpire holds a SOC 2 Type 2 attestation as a service organisation, the audit evidence for what 3AM did in your environment lives in your environment, in storage you control, with retention you set.

What gets logged

The audit log records the issuance and policy layer. CloudTrail (which you already operate) records the AWS API layer. The two are complementary:

• CloudTrail captures every AWS API call AxelSpire's deployment role makes — the infrastructure-level evidence: which APIs were invoked, with what parameters, by which session, at what time, from which source IP.
• The 3AM audit log captures the higher-level intent:
  • Every certificate issued: subject, SAN(s), policy version evaluated, backend CA that fulfilled the request, requesting consumer identity, time
  • Every revocation
  • Every policy change: what changed, who approved it, the diff against the previous version
  • Every AxelSpire deployment action: which 3AM stack, which version, which configuration, which approval gated it
  • Every drift detection result

CloudTrail tells you what happened at the AWS API surface. The 3AM audit log tells you what was issued, against which policy, and on whose authority. Object Lock compliance mode applies to the 3AM audit log; CloudTrail's own integrity is governed separately by AWS's standard CloudTrail validation model (log file integrity validation, organisation trail to a separate account, etc., as you configure them).

The audit log architecture in detail

S3 Object Lock has two modes that look superficially similar but differ on the question that matters for compliance:

• Governance mode allows users with a special permission (s3:BypassGovernanceRetention) to override retention. Useful for internal data with retention you want to enforce most of the time but not categorically.
• Compliance mode has no override. Once the retention date is set, no one can modify or delete the object before that date — not the customer's root user, not AWS Support, not AxelSpire, not anyone with any combination of permissions. The only way an object leaves the bucket is when its retention date passes and someone explicitly deletes it.

3AM uses compliance mode. This is the primitive that makes the audit log defensible against an inside-threat scenario, a compromised customer account, a compromised AxelSpire, or a regulator's "show me the immutable record" request.

Retention is set per-object at write time, derived from the deployment-level retention configuration. Default is 7 years, which matches SEC 17a-4(f) for broker-dealer records and exceeds HIPAA's six-year minimum for documentation. Higher retention (10, 25, 50, 100 years) is selected at deployment time for cases where regulatory or contractual requirements specifically demand it — for example, certain healthcare research data, certain financial instruments, or jurisdiction-specific recordkeeping rules.

Framework mapping

The architectural properties above map to specific control areas across the frameworks most enterprise PKI buyers face. The mapping below is structural — these are not "we comply" claims but "this is the evidence the auditor will see" claims. Your own framework certification or attestation remains your responsibility against your environment as a whole.

The framework set above is illustrative, not exhaustive. The high-information mapping is to controls about what is logged, by whom, and whether it can be tampered with — the area where 3AM's architecture is genuinely structurally distinct, rather than the areas where every CA platform makes similar claims.

Retention requirement calculator

For a first-pass retention value across the frameworks above, select the ones that apply to your environment. The tool returns the controlling rule citations and a recommended retention (the maximum of the applicable rules, plus a small safety margin). Orientation only — specific framework interpretations vary by auditor and jurisdiction.

What auditors actually ask, and how 3AM answers

Audit interviews about a managed PKI service tend to circle the same questions:

• "Show me the key custody chain." Private keys are held by AWS KMS in HSMs validated to FIPS 140 (AWS publishes the validation certificate references). HSMs are operated by AWS; access is governed by the customer-managed key policy, which lists your break-glass roles, not AxelSpire. AxelSpire's deployment role can invoke the key for issuance during the windows the deployment tier permits, but cannot extract or export key material. Evidence: KMS key policy, CloudTrail records of every key invocation, KMS HSM validation certificate.
• "Show me the access audit for the vendor." Every AxelSpire action is via STS AssumeRole into the deployment role. Each session has a unique session identifier and a session lifetime measured in minutes. CloudTrail captures every API call. The 3AM audit log captures every issuance and policy decision authored by AxelSpire's deployment workflow.
• "Show me the policy enforcement evidence." Policy is declarative and version-controlled. The audit log records, for each issuance, the policy version evaluated and the decision (approve/reject). For any historical date, you can reconstruct what policy was in effect, who authored it, who approved it, and which issuances were granted under it.
• "Prove the vendor cannot retroactively rewrite the audit log." Object Lock compliance mode. The S3 GetBucketObjectLockConfiguration API returns the configuration, including retention period and mode. AxelSpire's deployment role does not have permissions to change the Object Lock configuration; that permission is held by your break-glass roles. Even if it did, compliance mode is the AWS-enforced primitive that prevents modification regardless of permissions.
• "What happens if the vendor disappears?" The 3AM account is in your AWS Organization. The CMK is yours. The audit log is yours. The IAM roles are administered by you. AxelSpire's continued involvement is a convenience for ongoing operational changes, not a dependency for the existing audit evidence. Operational continuity is a separate question covered in 3AM deployment.

What 3AM does NOT do for compliance

Honesty about the boundary is part of the compliance argument:

• 3AM is not a Qualified Trust Service Provider (QTSP) under eIDAS. If you need eIDAS qualified certificates — qualified electronic signatures, qualified seals, qualified web authentication certificates, qualified time stamps — those must be issued by a QTSP listed on an EU member state's trusted list. 3AM is not in that scope. AxelSpire's PKI consultancy can advise on integration with QTSP-issued certificates separately.
• 3AM does not turn a private CA into a publicly-trusted one. Browser-trusted TLS certificates require issuance by a CA/B Forum member CA chained to a root in browser/OS trust stores. 3AM Mint, the standalone CA mode, is a private CA. For publicly-trusted certificates, 3AM integrates as a control plane in front of a public CA (DigiCert, Sectigo, Let's Encrypt, etc.); the trust comes from the public CA, not from 3AM.
• 3AM provides architectural properties, not certification-as-a-service. Your SOC 2, ISO 27001, FedRAMP, PCI DSS, or HITRUST attestations are yours to obtain against your environment. 3AM's properties make those attestations easier to obtain for the components in scope; they do not substitute for the audit and attestation work itself.
• AxelSpire's own corporate certifications, where applicable, are provided separately on request as part of the vendor due-diligence process. The compliance posture described on this page is about the architecture of 3AM as deployed in your account, not about certifications AxelSpire as a company holds.

Retention and legal hold

Default retention is 7 years, configurable at deployment from 1 to 100 years. Two operations matter for ongoing compliance:

• Increasing retention is supported via Object Lock retention extension. This is how legal hold is implemented: when an event triggers a litigation hold or regulatory inquiry, retention on the relevant objects is extended forward. Compliance mode means the extension cannot be reversed before the new date — even by a customer principal, even by AWS root.
• Decreasing retention below what was originally set requires a separate operation that re-applies the onboarding module with the new value, and the new value applies only to objects written after the change. Existing objects retain their original retention. This is the AWS-enforced semantic, not a 3AM choice.

The combination matters for the regulator question "can a customer or vendor shorten retention to make evidence go away?" The answer for objects already written is no, regardless of who is asking and regardless of permissions held.

How this differs from vendor SaaS CA compliance

A managed CA delivered as vendor SaaS typically holds the audit log, the compliance attestations, and the retention policy on the vendor side. The customer's compliance posture inherits the vendor's certifications and is bounded by the vendor's audit export interface — what the vendor will export, in what format, on what cadence, with what retention guarantees.

3AM inverts this. The audit log is in your AWS account from the moment it is written. Object Lock compliance mode is the AWS-primitive guarantee, not a vendor SLA. Retention is your decision. Export is irrelevant — the log is already where your auditors look.

The vendor risk management implication: the supply-chain risk an auditor evaluates for 3AM is "AxelSpire's deployment workflow may go away," not "AxelSpire's audit retention or export interface may change." The first risk is recoverable via the vendor access model in 3AM deployment — detach the trust policy and AxelSpire is gone, while the existing audit evidence remains in compliance-mode storage in your account. The second risk, common to vendor SaaS, has no equivalent in 3AM's deployment model.

Frequently asked questions

Is AxelSpire SOC 2 / ISO 27001 / FedRAMP certified as a company?

AxelSpire's own corporate certifications, where applicable, are provided separately on request as part of vendor due diligence. The compliance posture on this page is about the architecture of 3AM as deployed in your AWS account, which is independent of AxelSpire's corporate certification status. Most of the audit evidence an auditor will review is in your environment, not AxelSpire's.

Can we point our auditor at 3AM's architecture documentation directly?

Yes. This page, the 3AM deployment vendor access model, and the engineer-level reference in the Vault are the authoritative descriptions of what 3AM creates and how. Auditors typically also want to see the live configuration in your account — the Object Lock configuration, the KMS key policy, the deployment role's trust policy — which can be exported via standard AWS APIs.

How does Object Lock compliance mode differ from governance mode?

Compliance mode has no override. Once retention is set, no permission combination — including AWS root or AWS Support — can modify or delete the object before the retention date. Governance mode allows a special bypass permission. Compliance mode is the primitive recognised under SEC 17a-4(f), FINRA 4511(c), and CFTC 1.31; governance mode is not.

What if our regulator requires longer retention than the default 7 years?

Retention is configurable from 1 to 100 years at deployment. Set the value that matches your longest applicable requirement. Going higher than necessary is operationally cheap (S3 storage cost for the additional period); going below is the part that requires deliberate decision because it can change the regulatory posture.

Can we put the audit log on legal hold?

Yes. Object Lock retention extension is the mechanism. When a litigation hold or regulatory inquiry begins, retention on the relevant objects is extended forward; compliance mode prevents the extension from being reversed.

Does 3AM help us with eIDAS qualified certificates?

No, not directly. Qualified certificates require issuance by a QTSP listed on an EU member state's trusted list, which AxelSpire is not. 3AM can act as a control plane in front of a QTSP-issued certificate workflow for the parts that are not the qualified issuance itself; AxelSpire's PKI consultancy can advise on the integration design.

How does 3AM support PQC migration for federal mandates?

US federal post-quantum cryptography requirements derive from NSM-10, OMB M-23-02, EO 14144, and the Quantum Cybersecurity Preparedness Act. The relevant NIST inventory and migration timelines are in NIST IR 8547. 3AM's centralised policy engine makes algorithm migration — adding ML-DSA-65, SLH-DSA-256, or any future algorithm to the issuance policy — a single policy change rather than N migrations across N backend CAs. The migration mechanics for any specific environment are scoped in AxelSpire's PKI consultancy.

Can the audit log be exported for long-term archival outside AWS?

Yes. The audit log is an S3 bucket; standard S3 replication, lifecycle policies, and export tooling apply. Most customers do not export — Object Lock compliance mode in S3 is sufficient for the regulatory frameworks that recognise it — but archival to a separate environment is supported where required.

Does the audit log contain personal data subject to GDPR or CCPA?

The audit log records subjects, SANs, and consumer identities of issued certificates, which may include personal data depending on what the certificates are for (e.g., certificates for individual employees or customers). GDPR and CCPA obligations follow the data, not the system. The customer remains the data controller; 3AM's role is to provide the storage primitives (encryption at rest, access controls, retention) that the controller's privacy programme requires. Specific data-subject-rights handling is part of the customer's privacy operations, not a 3AM feature.

Next steps

For the vendor access model, account isolation, and onboarding mechanics that underpin the compliance posture described here, see 3AM deployment: how it works in your AWS account. For multi-PKI integration, see 3AM control plane: unified issuance across multiple CAs.

For framework-specific questions against your environment, the fastest path is Ask Axel — the on-site assistant that has the full 3AM documentation indexed. For a compliance-review conversation with the AxelSpire team, including walking through the framework mapping for your specific regulatory profile, contact us.

Related Resources

About AxelSpire and 3AM

AxelSpire is a B2B PKI consultancy and product company founded by Dan Cvrcek, with roughly a decade of PKI architecture across financial services and high-volume internet/operator environments and post-doctoral research at the University of Cambridge. AxelSpire's core product, 3AM (AxelSpire Automated Management), is a serverless certificate authority and multi-PKI control plane built on AWS KMS. AxelSpire operates in the US, UK, and EU, with additional regions on request.

Authored by Dan Cvrcek (AxelSpire). AxelSpire is a vendor-neutral PKI and certificate lifecycle management consultancy.