PSCO.ai
Log inGet a quote

Compliance

Every framework still assumes a person other than the author approved the change.

PSCO satisfies the independent-review and segregation-of-duties expectations in every major framework the target customers hold; PCI DSS even names third-party reviewers as acceptable. This table is the backbone of the compliance pages and the Auditor Guide.

The mapping

FrameworkControlWhat it asksHow PSCO satisfies it
SOC 2 (2017 TSC)CC8.1 Change managementChanges are authorized, designed, tested, approved and implemented; auditors sample merged PRs for an approver other than the authorNamed Officer approval on every PR; attestation record per PR; monthly Evidence Pack laid out for sample testing
SOC 2 (2017 TSC)CC6.1, CC6.3 Logical access and segregationAbility to change production is restricted and segregatedBranch protection requires PSCO approval and the psco/approved check; authors cannot self-approve; PSCO never merges or deploys
ISO/IEC 27001:2022A.5.3 Segregation of dutiesConflicting duties are segregatedDeveloper and approver are different people in different organizations, recorded on every change
ISO/IEC 27001:2022A.8.32 Change management; A.8.25 Secure development life cycle; A.8.28 Secure codingChanges follow a controlled process; secure coding principles are appliedThe model encodes the secure-coding rules and required gates; every change is checked against them before release
PCI DSS v4.0.16.2.3, 6.2.3.1 Code review before releaseManual reviews by "individuals other than the originating code author" who know secure coding, approved by management; "knowledgeable third-party personnel" allowedOfficers are qualified third-party reviewers; the Approved Review is the review; the customer's release owner merging is the management approval
HIPAA Security Rule45 CFR 164.308(a)(1)(ii)(B) Risk management; 164.308(a)(8) EvaluationNo explicit code-review rule; assessors expect documented SDLC controls proportional to ePHI riskePHI-handling paths are Deep Review by default; evidence of review on every change touching them
NIST SP 800-53 (FedRAMP); NIST SP 800-171 (CMMC Level 2)AC-5 Separation of duties; CM-3 Configuration change control; SA-11 Developer testing; 800-171 3.1.4, 3.4.3Separate duties; track, review, approve and log changes with security impact analysisUS-persons-only reviewers; documented approval with security review on each change
SOX ITGCProgram change managementDevelopers cannot approve or promote their own changesIndependent approver on every change; Evidence Pack maps to change-population testing

Before these pages go live

The PCI DSS 6.2.3.1 wording is from a third-party summary and the other control references are cited from the standards. Verify each against the published text before quoting it to an auditor.

Two things make the mapping hold up in the room

Name the Officer in your control. Be able to produce the Dossier.

First, the customer's control description must name the Officer. Second, PSCO must be able to produce the Officer Dossier and the full population of attestation records on request, without the customer assembling anything.

Suggested control wording

All changes to production code require approval from a qualified reviewer who is not the author. Reviewers are PSCO Officers, background-checked US-based engineers contracted by the company, who review each change against the company’s Security & Compliance Model before approval.

Watch item

The AICPA is updating SOC 2 for emerging technology, with draft guidance expected in Q4 2026. If it formally accepts AI-only approval for low-risk changes, PSCO's position shifts from required approver to the human-oversight control over the AI reviewer, which ISO/IEC 42001 and the EU AI Act already ask for.

One page per framework

Your auditor has questions. The Auditor Guide answers them.

Each framework page has the guide for download, plus the control wording to paste into your policy.

Get a quote in 2 minutesBook a meeting