A scan that becomes audit evidence

In Perimeter, a finding isn’t just a row in a CSV — it’s a timestamped, control-referenced, cryptographically signed artifact you can hand an auditor or an insurer. This page covers control mapping, per-finding evidence records, and the signed audit binder.

1 · Control mapping — every finding ties to a framework

Each finding has a category (e.g. vulnerability management, patch remediation, TLS/crypto, exposed service, attack-surface drift). Perimeter expands that category into specific control IDs across six frameworks. Expand any finding to see the control chips.

Framework	Example controls Perimeter maps to
NIST CSF 2.0	ID.RA-01 (vulnerabilities identified), PR.PS-02 (software maintained), ID.RA-06, PR.DS-02, ID.AM-01
SOC 2	CC7.1 (vulnerabilities identified & monitored), CC6.1, CC6.7
PCI DSS 4.0	11.3.1 (internal scans), 11.3.2 (external scans), 6.3.3 (patch timeframe), 4.2.1 (transmission crypto), 2.2.6
ISO 27001	A.8.8 (technical vulnerabilities), A.8.24 (cryptography), A.8.9, A.8.30
CMMC L2 / NIST 800-171	RA.L2-3.11.2 (scan), RA.L2-3.11.3 (remediate), SC.L2-3.13.8, CM.L2-3.4.6
Bastion 800-171 practices	3.11.2 / 3.11.3 (RA-5), 3.14.1 (SI-2), 3.13.8 (SC-8), 3.4.6/3.4.7 (CM-7) — these become POA&M items in Bastion when open + KEV/critical.

Open KEV or critical findings in patch/vuln categories are flagged with “open KEV/critical → POA&M item” — the trigger for a Plan-of-Action-and-Milestones entry in Bastion. The full category → control table lives in assets/data/control-map.json.

2 · The per-finding evidence record

This is the flagship artifact. Expand a finding and click Signed evidence record to download a JSON file that turns that one finding into a complete, self-describing audit-evidence object. It contains:

Section	What’s in it
finding	id, title, category, CVE, CVSS + vector, risk score, exploit tier.
asset	the assessed object: identifier, type, exposure, criticality.
detection	engine(s), confidence (single-source vs confirmed), corroborating engines, the de-noise verdict + signal, first/last seen.
exploit_intel	EPSS score + percentile, KEV status + due date.
remediation	status, owner, SLA due, age in days, overdue flag, fixed-at, and any risk-acceptance (who/reason/expiry).
evidence	the raw detection excerpt.
controls_satisfied + bastion_practices	the framework control IDs and 800-171 practices this finding produces evidence for.
evidenceRefs	the same controls in the Keystone canonical evidence_refs shape (ref_type = control \| framework) so the record publishes to the shared graph unchanged.

In plain terms: the scan output is the audit evidence. You don’t write a separate report saying “we scanned and found X” — the record proves it, with a timestamp and a control reference.

3 · Signed & tamper-evident

An evidence record is only worth handing an auditor if it can’t be quietly edited afterwards. Perimeter wraps each record in a detached HMAC-SHA256 signature over a canonical (key-sorted) serialization, with the signing timestamp bound into the signed material so it can’t be back-dated either. Any change to the record — a single character — breaks verification.

The downloaded file is { record, signature } where the signature carries the scheme (HMAC-SHA256), the signed-at timestamp, and the MAC value.
To verify, recompute the HMAC over the canonical record + timestamp with the same key and compare. A match means the evidence is byte-for-byte what was signed.

Deferred / hosted About the key. Locally, a non-secret demo key signs the record so the whole flow works end-to-end with no server. In the cloud tier the real signing key is a per-tenant secret minted and held in Keystone — the browser never sees it. Signing happens server-side when an evidence pack is sealed to durable storage; you receive a record you can verify but never the key. So a locally-signed record proves integrity (it wasn’t tampered with), and a cloud-signed record additionally proves provenance (it came from your tenant). See Security & privacy.

4 · The evidence pack (audit binder)

Where a per-finding record is one artifact, the evidence pack is the whole binder: every finding as a record, wrapped with metadata (product, schema version, generation date, count). It’s the self-describing bundle you’d hand over for an audit. The same structure underpins the printable compliance report packs.

5 · Printable compliance report packs

Open the Reports / export tab. Alongside CSV and JSON export, you can generate a framework-specific report pack:

Pack	What it evidences
PCI DSS 4.0 — Req 11.3	Internal + external vulnerability scans performed and findings remediated (11.3.1 / 11.3.2).
HIPAA Security Rule 2026	Recurring vulnerability scanning + remediation tracking now mandatory under the 2026 rule.
SOC 2 — CC7.1	Vulnerabilities are identified, monitored, and remediated with owners and due dates.
CMMC L2 / NIST 800-171	Open + remediated findings mapped to RA.L2-3.11.x for the SSP and POA&M.
Full report	All frameworks at once.

Each pack renders an executive summary (open / KEV / critical+high / overdue / remediated), a top-risks table, and a control-evidence appendix listing each control with a count of findings producing evidence for it. Click Print / save as PDF to produce the document.

Deferred / hosted Server-side PDF generation and signed durable storage of the report are deferred; the client renders the print-to-PDF view from the same structured model the server will use.

6 · Where the evidence goes (cloud)

When you publish from the Cloud tab, only a de-identified summary (open/KEV/critical counts, control refs, scan recency) becomes a canonical evidence object on the shared graph — Sightline maps it across 22+ frameworks and Bastion turns open KEV findings into POA&M items. Raw scan output and hostnames never leave your browser. See Cloud & entitlements.

Next: Feeds & scheduling, or troubleshoot a signature with Troubleshooting: evidence signature.