“Prove this screen behaves” — as a diff.
Auditors want documented, approved change control and a trail of who changed what. Because a Blueprint screen is a contract in version control, every change is a pull request — reviewed, approved, and permanently recorded.
The honest version: this isn’t one law — it’s a control expectation across SOC 2, PCI DSS, NIST 800-53 and SOX IT General Controls.
The same expectation, in every framework you’re audited against.
There’s no single “change-control law.” The same two demands recur across SOC 2, PCI DSS, NIST 800-53 and SOX ITGC.
- Every change moves through a defined process — authorized, tested, approved — before production.
- SOC 2 CC8.1 (authorize → test → approve → implement), PCI DSS §6.5.1 (documented approval + testing + back-out), NIST 800-53 CM-3 (review + approve with impact analysis).
- The change history is retained and reviewable — reconstruct what changed, when, by whom, and who approved it.
- NIST 800-53 CM-3 (retain records + review activity), SOC 2 CC8.1, and SOX IT General Controls (via PCAOB AS 2201) all require it.
Why a builder-based UI has no answer here.
When UI logic lives inside a builder, there’s often no diff, no PR, and no way to search for what a change affected — “who changed this screen and why” has no answer.
A payload that can change on a vendor’s server without your deploy has no change-control record on your side at all.
Screenshots and click-throughs aren’t an audit trail; auditors want a reviewable record with named approvals.
A screen change is a code change, framework by framework.
What an auditor sees: the change, as a reviewed diff.
Author, reviewer, timestamp, and the exact change — all in your version-control history.
{ "type": "form", "id": "statement", "fields": [ { "type": "amount", "rounding": "floor" } { "type": "amount", "rounding": "half-even" } ] }
Changes that skipped review
Change record
- Author j.rossi
- Approved by @audit
- Trail permanent (git)
The honest part
“Audit & change control” isn’t a single regulation — it’s a control expectation shared by SOC 2 (CC8.1), PCI DSS (§6.5.1–6.5.2), NIST 800-53 (CM-3), and SOX IT General Controls. Blueprint doesn’t certify you against any of them; it makes screen changes behave like code changes — versioned, reviewed, and permanently recorded — which is what those controls ask for.
The questions your compliance team will ask.
Is this a specific regulation?
No. Documented change control plus an audit trail is a control expectation across frameworks — SOC 2 CC8.1, PCI DSS v4.0 §6.5.1, NIST 800-53 CM-3, and SOX IT General Controls. Blueprint maps onto all of them because screens are versioned contracts.
How is a screen change approved?
As a pull request in your VCS — reviewed and signed off by the owners your process defines, with CI checks on the contract before merge.
How do we roll back a bad change?
It’s a git revert: the contract’s history is the rollback path — which is exactly the “back-out procedure” PCI DSS §6.5.1 expects.
What’s the audit trail, exactly?
Your version-control history: author, timestamp, reviewer, and the diff itself — retained and reviewable, as NIST 800-53 CM-3 requires.
Verify it yourself.
Each demand on this page is backed by a real, named framework.
- Change controlNIST SP 800-53 Rev 5 — CM-3, Configuration Change Control — review/approve with impact analysis; retain and review change records.
- PCI DSSPCI DSS v4.0 — §6.5.1 / §6.5.2 (PCI SSC Document Library) — documented approval, testing, back-out. (In v4.0 change control is 6.5.x; injection moved to 6.2.4.)
- SOX ITGCPCAOB AS 2201 — Audit of Internal Control over Financial Reporting — the ICFR audit standard behind SOX IT General Controls (change management is ITGC practice, not a numbered clause).
- SOC 2AICPA — Trust Services Criteria (CC8.1) — change management common criterion. (Free download, gated behind a form.)