Catalog · 10 frameworks · 1 single control · Public Beta

Control template catalog

Paste-in CALM control snippets for the most common compliance frameworks. Each template carries the requirement schemas and config shapes that ArchRails’ deterministic constraint engine evaluates at PR time. Drop the snippets onto the nodes the framework applies to, fill in your config, open a PR — the engine validates the rest.

Public Beta. Every template here is v0.1.0-beta. They’re unverified reference implementations — ArchRails is not a QSA, auditor, DPA, NCA, or NYDFS-recognised advisor. The authoritative regulations govern where the template and the regulation diverge. Engine evaluation is deterministic regardless of beta status; the label sets expectations on the snippet content, not on what the validator does.

Frameworks

Single controls

Standalone control templates for narrow, common requirements that don’t need a whole framework attached.

Sensitive data in logs Beta

Block secrets and PII from being written into application logs.
sensitive-data-in-logs/v0.1.0-beta

How to use these

Open the framework page and find the control you want to enforce (each is identified by a control-id like gdpr-access-restriction or soc2-cc6.1-iam).
Copy the JSON snippet directly under the “Control snippets” heading on that page.
Paste it into the controls object on the node, relationship, or flow the framework applies to in your *.calm.json. The Controls lesson covers the attach-point mechanics.
Fill in the config block with your environment’s actual values (or set config-url to point at a config document you maintain). The schema at requirement-url is what validates these.
Open the CALM-edit PR. ArchRails runs calm validate on the schema shape. Subsequent code PRs against any file mapped to that node will trip the constraint engine, which evaluates your config against the requirement schema deterministically. Failures surface as AR-CTRL-001 findings with the customer’s own control-id on the wire.

Which framework goes on which node?

There’s no algorithmic answer. The customer reads the regulation, the template’s applicability section, and decides the scope. Common patterns:

Framework	Typical scope
PCI DSS v4	Cardholder data environment (CDE) nodes only.
GDPR Art. 32	Any service touching EU personal data — usually most user-facing nodes.
HIPAA Security Rule	ePHI-touching services + databases.
MiFID II / RTS 22	Trade execution, transaction-reporting, clock-sync nodes.
SOX 404 ITGC	Anything affecting financial reporting.
SOC 2 TSC	Per the chosen trust services criteria (Security mandatory; Availability / Confidentiality optional).
NIST CSF 2.0	Org-wide; typically all nodes get Protect (PR) + Detect (DE) controls.
ISO 27001 / Annex A	Org-wide; typically all nodes get A.8 Technological controls.
DORA	EU financial entities — all critical or important ICT services.
NYDFS Part 500	NY-licensed financial entities — all information systems.

A single node in a regulated financial-services environment can legitimately end up with controls from 5+ frameworks. That’s normal — the constraint engine runs every attached control independently.