Compliance frameworks

A framework mapping turns what the cluster did into what an auditor asked for. It does not turn either one into a certification.

What an evidence package contains

For a period you choose:

• every admission decision, allows included, with the image, the digest, the reason and the policy that produced it — down to a content hash of the policy as it stood at that moment, so a decision is read against the policy text it was actually made under,
• the exceptions that were active, who approved each one and when it expired,
• scan coverage: which digests were evaluated, against which database version, and when,
• gaps, stated as gaps — periods where the webhook was not answering, or the quota was exhausted, appear as what they were,
• the population, reconciled: every running container's observed imageID checked against the admission ledger, so the document can say not only "the control decided N times" but "and here is what is running that it never decided on" — workloads that predate the install, entered during a gap, or slipped through under failurePolicy: Ignore are listed by name rather than left invisible.

Depending on what the installation has switched on, the document also carries a provenance record for images whose build provenance was verified, a vex section listing the findings a trusted producer's statement suppressed and the words they used, a runtime section of the events your own Falco delivered and what your runtime rules decided about them, an issues section of the tracker issues opened and closed for critical findings, and a context section saying whether admission escalated on where the pod was going to run.

The allows matter as much as the denials. Evidence that only lists blocks can show that something was blocked; it cannot show that a control was operating.

Reading report.json

Only report.json, and the PDF named beside it, is signed; the PDF renders the same data and never adds to it. A package keeps the shape it was generated with: one generated before a field existed does not have it, is never regenerated, and reads exactly as it did. Treat a missing field as "this package predates it", not as an error. The fields below arrived in 1.2.0.

Requirements: status, result, tests

Every entry of framework.requirements[] keeps status (met, partial, gap, outside_scope), note and evidence[], and adds two fields in OSCAL's words, derived from status:

framework.summary counts satisfied, not_satisfied and not_applicable beside the four status counts. tests[] lists what answered the requirement, one entry each:

Every requirement carries at least one test. The SOC 2 and EU CRA/NIS2 requirements are written as their own assessments and each is its own test. An outside-scope requirement carries one EXAMINE test, not-applicable, with the reason as its observation; a clause with a limb no record speaks to carries that limb as one more EXAMINE test, not-satisfied, because it is what holds the clause below met. The PDF prints the tests beneath each requirement.

The admission population

admission.records[] is every admission review of the period, one row each: at, namespace, pod, image, digest, allowed, reason, policy_name, policy_hash, break_glass, cached, requester. There is no cap — a population that stops at a limit is a sample — and admission.records_truncated is always false. The grouped denials and the chain[] DEPLOY rows stay as the readable summary; records is what a sample is drawn from. The PDF prints how many rows there are and where they are, not the rows.

How the document was produced

generation states when and by what the document was generated (generated_at, generator), the source_system, the query period — end exclusive, timezone: UTC — and queries[]: for each section, the query behind it in words and the number of rows it returned. The two capped queries say whether they hit their cap: runtime.decisions at 500 and, when asked for, runtime.raw_events at 5000. actors gives the actor scheme and unresolved_rows, described below.

Runtime clocks

event_time is the time field of the Falco event, and the one to argue from when a row is compared with the detector's own log. Coverage measures the feed reaching the operator, which only the operator's clock can show. The rule changes, triage releases and integration changes of the period are in runtime.audit_entries[], each with its kind.

Operator declarations

organisation.declarations carries time_source and retention_policy, the operator's own statements entered under Settings > Organisation > Operator declarations. The product does not measure clock synchronisation or enforce a retention period, and the PDF labels both lines "declared by the operator". Empty when nothing was declared. No framework clause reads them.

Personal data in evidence packages

An evidence package leaves the operator's hands. From 1.2.0 it names accounts, never people.

Console accounts are written by id. Every person field is user:<account id>: the predicate's generated_by (and so the README's "Generated … by" line), chain[].actor for audit-log rows, triage[].triaged_by and runtime.audit_entries[].actor. The console's audit log still shows names: it is the operator's own record, and it is where the operator resolves an id to a person when an auditor asks. system (a sweep) and anonymous (a request with no session) are not people and are written as they are.

Rows recorded before 1.2.0 hold only a name. At generation such a row is matched, by exact display name or by e-mail without case, against today's accounts, disabled ones included; if exactly one account matches, the row is written as that account's id. Otherwise it is written user:unresolved and counted in generation.actors.unresolved_rows, and the README says how many. Nothing is guessed, and the stored rows are not back-filled.

Accounts are disabled, not deleted. Deleting a user disables the account: it cannot sign in, its sessions end, and its id and name stay, so every user:<id> in an issued package still resolves. For an erasure request an administrator can then Anonymise the disabled account. In one transaction that blanks its name, e-mail and avatar and rewrites every copy of its name in the audit log, triage decisions, and runtime policies and their revisions to user:<id>. Where another account bears the same display name, a row matched by name alone could be either person's and is left as it is. The response and the audit entry state how many rows were rewritten and how many were left. The rows themselves stay: an erasure request does not delete the security log, it stops it naming the person. Packages signed before the anonymisation keep what they were signed with, and comments already posted to an external issue tracker are not rewritten.

The cluster copy of a triage decision names the account. The triagedBy of an ImageSecurityReport triage entry is user:<account id>: the report is a cluster object that no anonymisation reaches, so no name is written there. Entries written before 1.2.0 hold a display name and are not patched; an entry written by the kubectl plugin leaves the field empty.

Kubernetes identities are pseudonymised. admission.records[].requester is written as the API server gave it when it is a system: identity — service accounts, controllers. Any other username, an OIDC e-mail or a certificate CN, is a person, and is written k8s-user:<first 16 hex characters of the SHA-256 of the username>. The raw username stays in the admission ledger, where the operator resolves the pseudonym on request.

Free text is not rewritten. Break-glass approvers, triage justifications, block release notes and audit-log details go into the package as they were typed. The console asks for a ticket or a role rather than a person's name under each of those fields; what is typed there is the operator's choice.

Deliveries name the package, not the recipient. Delivering or e-mailing a package from the console writes an audit entry whose target is the package; the recipient's address goes only into the entry's detail, which packages do not copy. Entries written before 1.2.0 carried the address as their target, and a package covering that period still shows it in chain[].

Contact fields are the organisation's. organisation.contact_email and security_contact are there because the Cyber Resilience Act asks for a reachable contact. Use a role mailbox, not a person's address.

Old packages are unchanged. A package generated before 1.2.0 was signed with names in it and keeps them.

Mapped frameworks

Thirteen, and 293 clauses between them.

The clause count is what the operator assesses, not what the instrument contains: a clause a cluster cannot answer is reported as outside scope with the reason, and those are included in the count above. NIS2 is mapped inside the CRA package because the two bind different subjects — the manufacturer and the entity — over the same evidence.

Community includes one framework, and it is yours to choose rather than a fixed one. A company doing only ISO 27001 should not be asked to pay for a SOC 2 mapping it will never open.

Where a translation stands between you and the text

Two of the mappings are read from a text that is not published in English, and they say so in every clause rather than in a footnote.

ISMAP. An English reference translation of the Control Criteria exists, but where its entry only points at ISO/IEC 27002:2013 the obligation is translated from the in-force Japanese edition of 1 August 2024, and the citation says which. Every clause also states whether the control it maps is one the programme requires a provider to implement — the basic statement requirement — because an assessor reads that distinction first.

ISMS-P. There is no official English text of the criteria at all. Every clause is our translation of the Korean criterion sentence as printed in KISA's guide, and each citation says which criterion it came from. Because an ISMS-P criterion states a technical measure and a procedure, a designation or a periodic review together, no criterion is reported as fully met: a cluster's records answer the first half only, and the mapping reports partial by design.

What this does not claim

Each mapping names the clauses a cluster cannot answer and marks them outside scope with the reason, so a reader holding the instrument finds them rather than an absence. What that means for the five newest:

• PCI DSS. This is not a Report on Compliance and not an Attestation of Compliance: those are issued by a Qualified Security Assessor or a qualified internal resource against the entity's whole cardholder data environment, and only the entity defines what is in that environment. Nothing here establishes that a cluster is in scope for PCI DSS or that it is out of it. The web application and payment page clauses of 6.4, the Approved Scanning Vendor scans of 11.3.2, the entity's own targeted risk analysis and the organisational programme of Requirement 12 are outside what a cluster observes.
• MAS TRM. The Guidelines are supervisory expectations addressed to a financial institution, and nothing here assesses the institution's technology risk management framework as a whole. Virtual machine images, hardware and network devices, endpoint protection, the hypervisor beneath the nodes, the institution's own approval processes — the change advisory board, segregation of duties in a release pipeline, the dispensation granted for continued use of unsupported software — and the independent IT audit function of section 15 are marked outside scope.
• ASD Essential Eight. Nothing here establishes a maturity level: the model is assessed against the organisation's whole internet-connected estate, by the organisation or a party it engages. Five of the eight strategies — restrict Microsoft Office macros, user application hardening, restrict administrative privileges, multi-factor authentication and regular backups — are outside what a cluster observes, and where a level states one window for internet-facing servers and a longer one elsewhere, the stricter limb is the one mapped, because a cluster does not know which of its workloads are reachable from the internet.
• ISMAP. The criteria are addressed to a cloud service provider and cover its whole undertaking; an assessment reads the provider's own statement of which controls it implements. Nothing here is that statement, nothing here assesses one, and nothing here registers anything. The governance criteria of attached table 1, the management criteria of attached table 2, human resource security, physical and environmental security, network security management and the access control criteria are outside it.
• ISMS-P. Nothing here is a certification audit and nothing here establishes conformity: an auditor from a certification body works through the criteria against the organisation. Domain 3, the requirements at each step of personal information processing, is outside it entirely, as are personal security, physical security, access control, application of encryption and disaster recovery.

Where the mappings come from

Each mapping is read from the published text of the framework and cites the clause it maps to, so you can check the reading rather than trust it. Where a clause is genuinely ambiguous about containers, the mapping says so instead of picking the flattering interpretation.