Compliance evidence
mipo supports evidence collection for frameworks like SOC 2 and ISO 27001. It does not certify compliance — your auditors determine whether each control is satisfied. This guide describes the evidence mipo produces and the boundaries of those claims.
Evidence workflows
Continuous port-state evidence
Scheduled scans + historical diffs produce a dated record of exposure changes over time.
Proof of execution
Every job ends with a receipt signed by the scanner that ran it — verifiable evidence even for a scan that found no change.
Change attribution
The audit log ties scan and config changes to an actor and timestamp.
Access-control evidence
RBAC scopes, OIDC, MFA, step-up re-authentication, and session records demonstrate logical access control.
Tamper-evidence
A SHA-256 hash chain over the audit log flags in-place tampering of historical rows; the integrity page verifies it on demand.
Database-enforced append-only evidence
Six chain-of-custody tables accept inserts only: no application role holds UPDATE or DELETE, and a trigger blocks mutation even from a privileged connection.
Retention
Audit events are kept 365 days by default (set AUDIT_RETENTION_DAYS in .mipo.env to change it), authentication events 180 days, data-access views 90 days, and raw scan results 90 days with the two most recent completed baselines per scope always kept. Export for longer archival.
How the evidence is produced
Scheduled scans plus historical diffing produce a dated record of exposure changes over time. The append-only audit log ties every scan and configuration change to an actor and timestamp, and a local audit-chain check flags in-place tampering of historical rows. RBAC scopes, OIDC, MFA enrolment, step-up re-authentication records for high-impact actions, and session records demonstrate logical access control. Together these provide a defensible, exportable trail rather than a point-in-time snapshot.
Append-only is enforced in the database, not just by convention: the evidence tables — audit events, scan results, scan and DNS job receipts, DNS observations — grant no update or delete privilege to any application role, and a trigger rejects mutation even from a privileged connection. The only process that removes evidence is the separate retention service, running as the database owner, after the retention window has passed.
Execution proof
Every port-scan job ends in a receipt signed on the scanner host with the private key behind its client certificate: the target and port set it was assigned, the probes it attempted versus those planned, and a hash over the open ports it observed. Ingest verifies the signature against the certificate the scanner presented and recomputes the result hash from what it actually stored before the receipt is written, so neither side can assert a result the other did not see. A delta scan that found nothing changed carries the same receipt, so an auditor can prove "we scanned on this date and found no change" rather than infer it from an empty diff. Reverse-DNS jobs produce the same artefact — observation batches plus a signed receipt per job, recomputed by the server before it is accepted. See Execution Proof, Job Receipt and DNS Job Receipt.
Retention
Evidence is tamper-evident for as long as it is kept, and it is not kept forever. Scan results and the reverse-DNS evidence that belongs to a closed scan are pruned 90 days after they close; the retention service also removes audit events older than its configured window (365 days by default). A pruned scan keeps a tombstone so later references still resolve, but the per-host detail is gone. Export the receipts, results and audit log you will need for an audit period before its evidence passes those windows.
Control mapping
| Control area | mipo features | Frameworks |
|---|---|---|
| Logical access control | RBAC scopes, OIDC/SSO, MFA (TOTP), step-up re-authentication, owner bootstrap, session management | CC6.1, CC6.2 / A.9.2, A.9.4 |
| Audit logging | Append-only audit trail, actor + timestamp, data access views, hash-chain integrity check | CC7.2, CC7.3 / A.12.4 |
| Scan-execution evidence | Scanner-signed execution receipts per job, append-only results and DNS observations | CC7.1, CC7.2 / A.12.4 |
| Change management | Config version tracking, scan scope history | CC8.1 / A.12.1.2 |
| Availability monitoring | Built-in alarm rules, scanner heartbeats, health endpoints | CC7.1 / A.17.1 |
| Asset management | Subnet inventory, port catalog, scanner registry | CC6.6 / A.8.1 |
| Encryption | TLS everywhere, scanner mTLS, backup encryption, credential encryption at rest | CC6.7 / A.10.1 |
| Incident response | Alarm lifecycle (open→acknowledged→resolved), notification channels | CC7.4 / A.16.1 |
mipo supports evidence collection. It does not certify compliance — your auditors determine whether controls are satisfied.
Where auditor judgement remains required
mipo maps capabilities to control areas as a starting point, not a determination. Whether a control is satisfied depends on your scope, your other controls, and your auditor's assessment. mipo's job is to make the underlying evidence complete, dated, and tamper-evident — the judgement stays with the auditor.