Standards Compass

The problem

“are we compliant?”  →  compliant with what?

Nobody decides which standards a product is built to. Not out of negligence — because the question never appears in a ticket. Then eight months in somebody asks whether the project is compliant, and the honest answer is that nobody knows what compliant would even mean for this product.

The instinct at that point is a checklist. Five hundred requirements produce five hundred shallow answers, most of them irrelevant, none of them trustworthy — and a team that now believes standards work is theatre.

What it does instead

profile  →  which of these applies here?  →  scope
   →  evidence  →  status + confidence + gap type
   →  deduplicate  →  prioritize  →  report

Nine standards considered, four assessed against, five ruled out with reasons. That ratio is the product. Telling a team that PCI DSS is not indicated because payments go through a hosted provider saves more work than most findings create.

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

What an audit looks like

You:    Audit this project.

Agent:  Applicable
          ✓ OWASP ASVS 5.0.0        authenticated multi-tenant app, untrusted input
          ✓ OWASP API Top 10 2023   SPA and mobile clients call the API directly
          ✓ WCAG 2.2                public web UI with interactive workflows
          ⚠ GDPR                    personal data present; jurisdiction unknown
          ⚠ PCI DSS v4.x            hosted checkout; scope determined with your acquirer
          ✗ HIPAA                   no clinical data or healthcare relationship observed

        3 high · 8 medium · 6 unable to verify

        Three administrative endpoints don’t enforce the authorization rule
        the other eleven use, and the export query at
        src/api/admin/exports.ts:31 has no tenant filter — so a signed-in
        member may be able to export another organization’s customers.

        Separately, there’s no evidence in the repository about backups,
        recovery, or incident handling. That’s not the same as their
        absence — those things normally live outside a codebase —
        but nobody can confirm them from here.

Two modes, one machine

You:    Add drag-and-drop file upload.

Agent:  Uploads bring a few requirements with them, so I’ll build it with
        server-side type and size limits, generated filenames, storage outside
        the web root, download authorization as strict as upload, and a
        keyboard-accessible file picker alongside the drop zone.

        [… implements …]

        ✓ Type allowlist and 25 MB limit enforced server-side
        ✓ Storage key is a generated UUID; original name kept as metadata
        ✓ Download authorization reuses the case access policy
        ✓ Drop zone has a keyboard-operable file input
        ⚠ No retention rule — case documents currently live forever.
          That’s a decision someone should make rather than a default.

A rename gets nothing at all. That silence is what buys the right to speak on the bulk customer export.

Not found is not failed

The distinction most standards tooling collapses, and the one that decides whether a report is trusted. No backup configuration in a repository means no backup configuration was found in the repository — backups usually live somewhere a codebase cannot see.

Writing a SECURITY.md does not create an incident response capability. Where the honest answer is a process gap, it says so and stops — a code change that papers over it makes the next audit less accurate.

What it will never say

✗ “This software is GDPR compliant”
✗ “The company is ISO 27001 compliant”
✗ “WCAG 2.2 AA conformant”
✗ “This application passed PCI DSS”

✓ “The repository appears to satisfy…”
✓ “Evidence consistent with…”
✓ “Gaps relevant to…”
✓ “Unable to verify.”

None of the first four is available from reading a repository, and all of them get quoted to customers, auditors and regulators. Certification and legal compliance rest on organizational process, policy, contracts, scope and independent assessment. This is an engineering standards assessment tool — not a certification body, an auditor, or a legal adviser.

One weakness, one finding

Missing authorization on 3 admin endpoints        ← one finding
    └─ OWASP ASVS · API Top 10 (API5) · NIST CSF PR.AA · ISO 27001 themes

Five frameworks care about authorization. Reported five times, nobody reads the second one. Findings are made against 36 normalized controls, and the standards attach underneath — so adding a standard extends every control it names, with no mapping table to maintain and nothing to drift.

A registry that can be kept current

registry/
  registry.yaml     categories, types, statuses, authority domains, schema
  controls.yaml     36 normalized control concepts
  <category>/*.yaml one file per standard — add one, nothing else changes

22 entries across security, quality, accessibility, lifecycle, privacy, AI, payments, industry and cloud — ASVS, OWASP Top 10:2025, API Security Top 10, MASVS, NIST CSF 2.0, SSDF, ISO/IEC 27001, ISO/IEC 25010, WCAG 2.2, EN 301 549, ISO/IEC/IEEE 12207, GDPR, CCPA/CPRA, ISO/IEC 27701, ISO/IEC 42001, NIST AI RMF, the EU AI Act, the OWASP GenAI LLM Top 10, PCI DSS, SOC 2, the HIPAA Security Rule and CIS Benchmarks.

Every entry records its version, status, official source, and when and how it was last verified — against the publishing body’s own site, or carried from bundled knowledge and marked as such. Reports say which, because a falsely verified entry is worse than an honestly unverified one. A validator enforces the schema, including that an official URL sits on the domain of the body that publishes the standard, so a vendor blog cannot become a citation. No copyrighted standard text is stored.

It gets better across sessions

.project-standards/
  profile.md                  what this software is, labelled
  applicable-standards.yaml   applicability decisions, and the negatives
  findings.md                 findings with status history and stable ids
  accepted-risks.md           what the team decided to live with, and why
  exceptions.md               intentional deviations, with compensating controls
  assessment-history.md       what was assessed when, and what changed

Which buys three things a one-shot audit cannot have: a dismissed finding stays dismissed, the second assessment is cheaper than the first, and a control that used to pass and no longer does is reported as a regression — with the commit that caused it — rather than rediscovered as a new problem.

It scales down, and up

A prototype told to build a governance programme ignores the whole report. A regulated system told to “add some tests” has been failed by it. Over-compliance is treated as a defect: every recommendation names the risk it reduces, or it does not go in.

Where it fits

Standards Compass decides what the software should be measured against. Impact Map maps what a change would touch, ProofBuild proves it does what it claims, Production Guard decides whether it is safe to ship, Engineering Investigator establishes what happened when it breaks, and Project Compass asks whether the ticket should have been written. None requires the others.

Limitations

• It reads a repository. Production configuration, organizational process, contracts, training and physical security are outside it — and it says so rather than guessing
• Legal applicability is never determined from code. Personal data means ask about jurisdiction, not GDPR applies
• Accessibility findings from source are real; accessibility conformance is not establishable without manual testing, and the report says which criteria were assessed by which means
• Infrastructure-as-code is evidence of intent. The cloud console is the fact
• The bundled registry ages. Entries carry a verification date and method, and reports quote them
• Severity is judgment informed by context. Being overruled costs one sentence