How control mapping works

StackTakt’s compliance model rests on one idea: deploying a template version asserts exactly the control set shipped with that version. The mapping is data, reviewed with the template, and snapshotted with each deployment, so what you see is what was true when the change applied.

The language rule

StackTakt describes demonstrated capabilities with citations, for example “SSE-KMS default encryption, mapped to HIPAA Security Rule 164.312(a)(2)(iv)”. It never asserts a compliance status: not “HIPAA compliant”, not “certified”, not “guaranteed”. Compliance outcomes belong to your program and your auditor; StackTakt’s job is to make the technical capabilities real and verifiable.

From template to deployment

1. Each blueprint version ships a control mapping: per framework citation, a status, the implementing resources, the evidence call that verifies it, and any caveats.
2. At apply time, StackTakt snapshots that mapping onto the deployment. Later template versions never rewrite an existing deployment’s asserted controls.
3. The snapshot also binds the deployment’s resources to the tenant’s control instances, which is what the Compliance matrix rolls up.

Statuses in a mapping: Implemented, Partial (always with a named caveat), Customer responsibility, and Inherited from AWS.

Frameworks and releases

Framework content lives in a versioned catalog release (requirements, controls, mappings, parameters). Releases are immutable: a published release is never edited, and corrections ship as a new release. Each tenant’s framework adoption pins a release, so your matrix does not shift under you when the catalog evolves.

The catalog covers the HIPAA Security Rule (see its page) and SOC 2 criteria. Framework parameters carry numeric floors (log retention, backup retention, key age) per framework, and the strictest adopted value wins when templates consume them.

How a requirement gets its status

The Compliance matrix evaluates each requirement over its contributors: every control StackTakt can deploy, evaluate, or inherit for it, plus its attestation document where one is owed.

• Demonstrated: every contributor is satisfied by an observed technical control.
• Inherited: carried entirely by AWS.
• Attested: covered by an approved, unexpired attestation document. Attested never reads as Demonstrated; a document is a recorded decision, not an observed configuration.
• Partial: some contributors satisfied, not all.
• Not demonstrated: an honest absence, deliberately never rendered red. A gap is not a failure finding.

The matrix shows the arithmetic per requirement (“2 of 3 satisfied”) and the reason for each contributor, verbatim. An open drift finding downgrades the bindings it affects until fixed or acknowledged.

Verifying it yourself

Every mapped control names the read-only AWS call that verifies it (s3:GetBucketVersioning, transfer:DescribeServer, and so on). The evidence package captures those calls’ answers at apply time, so an auditor can check the claim against the account rather than taking a screenshot’s word for it.