Compliance

Compliance evidence: how it is produced and how to verify it

The platform certifies no one. It measures real systems and delivers the result dated, hashed and signed, in the form an audit accepts. This page explains the mechanism and, at the end, shows how to verify the signature without taking our word for it.

How it works

A regime pack is the control-to-evidence mapping, versioned in our repository as code and reviewed as code. Each control names what the standard asks for, the clause that asks for it, and the rule the platform applies over what it already measures: diagnosis runs, verdicts, SBOM, coverage, the CI gate, merged pull requests, readiness and AI usage.

Nothing is filled in by hand. A control's status is a reading of measured evidence on the date it was read, and it changes on its own when the evidence changes. A control that stays with people, such as a written policy or incident handling, is marked manual: the platform lists it so the auditor knows it exists, and does not pretend to assess it.

Versioning the pack is how we monitor regulatory change When a clause changes, the pack gets a revision and a date, and older readings stay comparable. This is not a per-customer table, it is code.

The regime packs

Ten packs available. The customer picks which one to read; there is no per-customer configuration.

Regime	Jurisdiction	What the platform reads
CMN 4.893	BR, financial	Continuous cybersecurity, vulnerability management, segregation of duties in change
CFM 2.454	BR, healthcare	AI governance in clinical use, human oversight, record-keeping
ANVISA RDC 657	BR, healthcare	Software as a medical device: lifecycle and traceability
LGPD, arts. 46 to 49	BR	Technical security measures over personal data
ISO/IEC 27001	International	Secure development, supply chain, change management
SOC 2	US	Trust services criteria: monitoring, change and access
NIST SSDF	International	Secure software development practices
ISO/IEC 42001	International, AI	AI management: measured use, oversight, durability of generated code
EU AI Act	EU, AI	Read from the deployer side, which is the role most organisations hold
EU CRA	EU, digital product	Annex I Part II: SBOM, remediation without undue delay, regular testing

Each control cites the exact clause. Those citations are verifiable against the published text of the standard, and that is how they are meant to be read.

What each status means

Status is a reading, never a certificate.

Status	Meaning
Met	Measured evidence satisfies the rule on the date it was read.
Partial	Part of the scope satisfies it, part does not. The failing entities are named.
Missing	The evidence does not exist, or there is not enough data to assert. Absence of data never becomes compliance.
Stale	Evidence existed, but it is too old for the rule.
Accepted with exception	It fails, and the risk was formally accepted with an owner and a deadline. It never reads as met.
Manual	Stays with people. Listed for the auditor, not assessed by the platform.

Exceptions: the two exits

A failing control has exactly two exits: fix it, or accept the risk for a period. There is no third one. Registering an exception requires an owner, a justification and an expiry date, and only an organisation administrator can register it.

An exception never turns green The control stays failing underneath, shows as accepted with an exception, and goes back to failing on its own when the deadline passes. That is what separates evidence from a checkbox.

An expired exception raises an event and emails whoever approved it. The exception history goes into the dossier, so an audit sees not only today's state but what was accepted, by whom, and until when.

The dossier

The dossier is a zip generated on demand for an observation window. It contains:

The verdict and run history of every project measured in the window, with score, level, branch, source and the score version each reading was produced under.
The reading of every requested regime, control by control, with the evidence behind each status.
The window's exceptions, with owner, justification and validity.
Merged changes, PR by PR, with who opened them, who approved them and the commits.
SBOM per repository, the window's compliance events and the platform audit trail.
A readable summary.pdf, which is the same content as the manifest in prose.
A manifest.json with a SHA-256 per file, and an attestation.json with the platform's signature.

The window reaches 24 months, which is the declared retention. Historical runs are never recalculated: each one keeps the score version it was assessed under, so the past is not rewritten when the method evolves.

Verify it yourself

Check every file, the manifest and the signature using the verifier below. Obtain the public key independently from ScaleQuality for the attestation keyId; the key inside the ZIP is not a trust anchor.

First, the integrity of each file. The manifest declares a SHA-256 per file; recompute and compare.

shell

# Every file in the zip has a SHA-256 declared in the manifest.
# Recompute and compare: what you received has to be what was generated.
python3 verify-dossier.py dossier.zip trusted-public-key.pem

Then, the manifest signature. The platform signs the canonical digest of a stable subset of the manifest, and publishes the public key. Changing a file hash, the period or who generated it changes the digest and breaks the signature.

verify-dossier.py

# The signature covers this stable subset of the manifest, and nothing else.
# Download the verifier from /tools/verify-dossier.py.
# Obtain trusted-public-key.pem independently from ScaleQuality for the keyId.
# Never use the key inside the ZIP as the trust anchor.
python3 -m pip install cryptography
python3 verify-dossier.py dossier.zip trusted-public-key.pem

verify-dossier.py

When the signature is HMAC If the organisation was attested before an Ed25519 key existed, the algorithm shows as HMAC-SHA256. The digest check is identical, but signature validation goes through the API at /api/insights/dossier/attestations/:id/verify, because the key is the platform's. Ed25519 is the mode where a third party verifies on its own.

Consume it through the API

The same reading is available over the API, so a GRC tool or an engineering portal consumes it directly, with no manual collection.

shell

curl -H "Authorization: Bearer sq_live_..." \
  "https://app.scalequality.io/v1/controls/org/<orgId>?regime=SOC2"

curl -H "Authorization: Bearer sq_live_..." \
  "https://app.scalequality.io/v1/evidence/org/<orgId>"

And what changes arrives over a signed webhook: every delivery carries an X-SQ-Signature header with HMAC-SHA256 over the raw body, using your organisation's secret. Verify the signature before trusting the event.

What stays yours

The boundary matters, and it is written here for the same reason it is written into the product:

Classifying risk under a regime is the institution's legal judgement. The platform stores the classification as a declared field, labelled as declared, and never presents it as measured.
Written policy, training, contracts and incident handling stay with people.
Certification and regulatory opinion remain with auditors and competent authorities.

The platform produces the technical evidence that supports those processes. That is exactly why evidence that is ready to hand over, and verifiable by whoever receives it, matters.

Healthcare: AI and compliance