Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What security evidence should your company keep?
Updated
Keep evidence in eight categories: access, change, vulnerability, logging, training, incident, vendor, and policy. Each proves a control operated, not merely that it was designed. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
Evidence-category pillar, last verified 10 September 2026 against the AICPA Trust Services Criteria (2017, with revised points of focus 2022), ISO/IEC 27001:2022 Annex A, NIST SP 800-53 Rev. 5, and PCI DSS v4.0.1. Those four are different kinds of authority: SOC 2 is an attestation against professional criteria, ISO/IEC 27001 is a certification standard, NIST SP 800-53 is a control catalogue, and PCI DSS binds through card-brand and acquirer contracts. None of them is a determination that a given framework applies to your organisation — that question is for counsel and your customer contracts, not for this page.
What this page is, and what it is not
Audience: a CTO, CISO, compliance owner, founder, auditor, or investor who wants to know which artifacts to have on hand before an audit, a customer security review, or a regulator question. It is written to be usable by an engineering team, not only by a compliance function.
This page is not legal advice. Reading it does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor, a certification body, or a regulator. Mapping a row below is a planning step, not a compliance conclusion. Last verified 10 September 2026.
It is also not a claim that every organisation needs all eight categories. Scope follows from what you sell, to whom, in which jurisdictions, and under which contracts. An organisation with no card data in scope has no PCI DSS obligation from that fact alone; an organisation that has never sought ISO/IEC 27001 certification is not in breach of Annex A. Work out applicability first, then work this list.
- Evidence is what shows a control operated over a period. A written policy shows intent; a screenshot shows a moment; a population of records with a reviewer's name and date shows operation. The last one is what an auditor tests.
- Two questions decide whether an artifact is useful evidence: can you produce the complete population it was drawn from, and can a reader tell who did what, when, from the artifact alone?
- Evidence has an owner. An artifact nobody is accountable for going stale is the artifact that is missing in audit week.
- The retention companion to this page is the retention checklist in this cluster. The storage and indexing companion is the audit evidence repository page. The operating-effectiveness companion is the page on proving a control works.
The eight evidence categories, what each proves, and who asks
This matrix is the spine of the whole cluster. Read the middle column as the control assertion the artifact supports, and the right column as the frameworks that ask a question in that area. A framework appearing in a row is not a finding that the framework applies to you. Last verified 10 September 2026. Not legal advice.
| Evidence category | What the evidence proves | Which frameworks ask (only where in scope) | Typical requester |
|---|---|---|---|
| Access — identity, authorisation, review | That only authorised people held access, that access was granted on an approval, removed on departure, and re-confirmed periodically. Joiner/mover/leaver records, access-review sign-offs, privileged-access lists, authentication configuration. | AICPA TSC CC6 (logical and physical access). ISO/IEC 27001:2022 Annex A 5.15–5.18 (access control, identity, authentication, access rights). NIST SP 800-53 Rev. 5 AC family. PCI DSS v4.0.1 Requirements 7 and 8, where cardholder data is in scope. | Auditor; enterprise customer security review; regulator on a specific incident. |
| Change — code to production | That changes were reviewed, approved, tested, and deployed through a controlled path, and that emergency changes were handled as exceptions rather than as the norm. Pull/merge request records, approvals, required checks, deployment records. | AICPA TSC CC8 (change management). ISO/IEC 27001:2022 Annex A 8.32 (change management). NIST SP 800-53 Rev. 5 CM family. PCAOB AS 2201 ITGC change controls, where a financial-statement audit reaches your systems. | Auditor; internal audit; a SOX programme where in scope. |
| Vulnerability — discovery to remediation | That you look for weaknesses on a defined cadence, prioritise them on stated criteria, remediate within stated targets, and document accepted risk. Scan coverage records, prioritisation rationale, remediation records, exception approvals. | AICPA TSC CC7.1. ISO/IEC 27001:2022 Annex A 8.8 (management of technical vulnerabilities). NIST SP 800-53 Rev. 5 RA-5 and SI-2. PCI DSS v4.0.1 Requirements 6 and 11, where in scope. | Auditor; enterprise customer; insurer. |
| Logging and monitoring | That security-relevant events were recorded, kept for a defined period, protected from alteration, and reviewed or alerted on. Log configuration, retention configuration, alert definitions, evidence of review or triage. | AICPA TSC CC7.2. ISO/IEC 27001:2022 Annex A 8.15 (logging) and 8.16 (monitoring activities). NIST SP 800-53 Rev. 5 AU family, and NIST SP 800-92 as guidance. PCI DSS v4.0.1 Requirement 10, where in scope. | Auditor; regulator after an incident; DFIR firm. |
| Training and awareness | That people were told what is expected of them, on a cadence, with role-specific content where the role warrants it, and that you can name who completed what. Completion records, curriculum, phishing-simulation results, policy acknowledgements. | ISO/IEC 27001:2022 Annex A 6.3 (information security awareness, education and training). AICPA TSC CC1.4 and CC2.2. NIST SP 800-53 Rev. 5 AT family, with NIST SP 800-50 as guidance. PCI DSS v4.0.1 Requirement 12.6, where in scope. | Auditor; enterprise customer questionnaire. |
| Incident management | That incidents were detected, classified, communicated, resolved, and reviewed, and that evidence was preserved rather than overwritten. Incident records, timelines, severity decisions, comms records, post-incident reviews. | AICPA TSC CC7.3–CC7.5. ISO/IEC 27001:2022 Annex A 5.24–5.28. NIST SP 800-53 Rev. 5 IR family, with NIST SP 800-61 as guidance. Statutory reporting regimes (for example GDPR Articles 33–34, NIS2, DORA, CRA Article 14) apply only where they apply. | Auditor; regulator; affected customer; insurer. |
| Vendor and third party | That third parties with access to your systems or data were assessed before onboarding, re-assessed on a cadence, and bound by contract terms that match the risk. Vendor inventory, assessment records, contract clauses, subprocessor list, received SOC 2 or ISO certificates. | AICPA TSC CC9.2. ISO/IEC 27001:2022 Annex A 5.19–5.23 (supplier relationships, cloud services). NIST SP 800-53 Rev. 5 SR family. DORA third-party provisions, for financial entities in scope. | Auditor; enterprise customer; financial-services regulator where in scope. |
| Policy and governance | That there is documented, approved, current direction — and that it was communicated. Approved policy set with version and approval date, risk assessment, management review records, roles and responsibilities, objectives. | ISO/IEC 27001:2022 Clauses 5–7 and 9 (leadership, planning, documented information, management review) plus Annex A 5.1. AICPA TSC CC1 and CC2. NIST SP 800-53 Rev. 5 PM and PL families. | Certification body; auditor; board and investors. |
Legal requirement, regulatory guidance, best practice, or our recommendation
The single most common evidence mistake is treating all four of these as the same weight. A contractual standard is not a statute. A NIST publication is not binding on a private company that has not contracted to it. A widely followed cadence is not a mandate. Label the reason each artifact exists, so the choice is defensible when someone asks. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirement 10.5.1: retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. | Legal requirement in the contractual sense — PCI DSS binds entities in scope through card-brand and acquirer agreements, and can be reinforced by statute in some jurisdictions. | Does not mean 12 months is the right retention for every log type in every organisation, and does not apply to an entity with no cardholder data in scope. |
| GDPR Article 5(1)(e): personal data kept in a form permitting identification of data subjects for no longer than is necessary for the purposes for which it is processed. | Legal requirement — a regulation with direct effect, where the processing is in scope. It pulls in the opposite direction from long log retention. | Does not set a number of months for security logs, and does not resolve the tension for you. That balance is a legal question on your facts. |
| NIST SP 800-53 Rev. 5 and NIST SP 800-92: control catalogue and log-management guidance. | Regulatory and standards guidance. Binding on US federal systems through separate authority; for a private company it is a well-regarded reference, not a rule. | Does not become a legal obligation because you cited it in a policy, though a contract can make it one. |
| AICPA Trust Services Criteria and ISO/IEC 27001:2022 Annex A. | Attestation criteria and certification requirements. They apply because you sought a SOC 2 report or ISO/IEC 27001 certification, or because a customer contract requires one. | Does not mean an organisation with neither is non-compliant with anything. Not a statute. |
| Keep a control-to-evidence index so every control names its artifact, owner, source, and freshness date. | Industry best practice. Widely expected by auditors as a matter of practice; not written as a requirement in the criteria themselves. | Does not substitute for the underlying artifacts, and an index alone evidences nothing. |
| Record the named human who accepted each manual evidence row, with a timestamp, and treat an unaccepted manual row as a gap rather than as met. | ShipReady Metrics recommendation. It is how this product behaves and what we advise; it is not required by any framework named on this page. | Does not make the row audit-ready by itself, and is not a chain of custody in the forensic sense. |
What makes an artifact usable as evidence
Most evidence is rejected for form, not for substance. The artifact is real and the control works, but the artifact cannot be tied to a period, a population, or a person. These are the properties an auditor looks for, drawn from how the AICPA criteria and ISO/IEC 27001 Clause 7.5 talk about documented information.
- Period: the artifact states the date or date range it covers. A screenshot with no timestamp evidences a moment nobody can place.
- Population and completeness: you can show the full set from which a sample was taken — all deploys in the period, all joiners, all privileged accounts. Sampling without a defensible population is the most common finding.
- Attribution: the artifact names the person or system that performed and, where relevant, approved the action.
- Source integrity: it is clear where the artifact came from, and that it was not editable after the fact by the person it evidences. An export generated by the system of record beats a hand-maintained spreadsheet.
- Freshness: the artifact is within the period under review, and you know when it will need refreshing.
- Mapping: the artifact is linked to the control it supports, so the reader does not have to infer the connection.
Checklist
This table is the checklist artifact for this page — work it column by column rather than downloading anything. It is a question list, not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Which frameworks and contracts are actually in scope for us this year, and who decided that? A framework in the matrix above is not in scope because it appears there.
- For each of the eight categories, can we name the system of record, the artifact, and the owner today — without a meeting?
- For each category, can we produce the complete population for the last twelve months, not only a sample someone remembers?
- Which artifacts exist only as screenshots or hand-kept spreadsheets, and which of those could be replaced by a system export?
- Which artifacts have no stated retention, and which have a retention that conflicts with a data-minimisation obligation?
- Which controls in our control set currently have no artifact at all, and are they recorded as gaps rather than quietly assumed to be met?
- Who reviews the evidence set between audits, on what cadence, and where is that review recorded?
What to do now
Ordered by what removes the most audit-week pain first. None of these steps is a legal determination, and none of them starts a clock or files anything with an auditor.
- Establish scope with counsel and your commercial team before collecting anything: which frameworks, which contracts, which jurisdictions. Collecting evidence for a framework you are not in scope for is cost without benefit.
- Write the control-to-evidence index for one category — access is usually the easiest to start and the most asked about. Name the artifact, the system of record, the owner, and the retention.
- Replace the two most fragile artifacts with system exports. A GitHub or GitLab export, a cloud audit-log query, or an identity-provider report is stronger and cheaper to refresh than a screenshot.
- Set retention per artifact using the retention checklist in this cluster, and separate legal minimums from best practice in that record.
- Record gaps as gaps. An honest gap list with owners is a better audit position than a control set that claims coverage it cannot evidence.
- Re-verify the framework citations you rely on against the primary sources listed below at least annually, and record the date you did it.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not decide which frameworks apply to you, does not produce an auditor's opinion, does not file anything with an auditor or a certification body, and does not automatically retain your SOC 2, ISO/IEC 27001, or CRA documentation pack.
If you already have a session: signed-in app → Compliance holds evidence collection, which records control-mapped artifacts for starter control subsets. Those control sets are starter subsets — illustrative, to be tailored by a compliance owner — not a complete control library and not legal advice.
Evidence review is the human overlay: a named human accepting a manual row can render that row met, and rejecting it renders it a gap, with a timestamp. That is a timestamped compliance artifact for a SOC 2 or ISO/IEC 27001-style programme. It is not a forensic chain of custody, not a downloadable evidence binder, not a regulator filing pack, and not an auditor's opinion.
The obligation map lists the frameworks your organisation marked in-scope. That mark is a scoping input you control; it is not a legal opinion that the framework applies. Readiness in this product is an internal indicator, not certification, not CE marking, and not an auditor's conclusion.
Connector-sourced evidence exists for some of the eight categories: the GitHub App is read-only and ingests Dependabot, code-scanning, and secret-scanning alerts as findings; GitLab security findings ingest similarly. Delivery Health computes DORA posture — deployment frequency, lead time, change failure rate, and time to restore — from connected sources including GitHub Actions runs. None of those exports your audit pack.
Primary sources (last verified 10 September 2026)
Every framework claim above is taken from one of these. If a later revision changes a requirement, the verification date is how you can see we have not re-checked since.
AICPA Trust Services Criteria (2017, with revised points of focus 2022) are professional criteria for a SOC 2 examination, not a statute. ISO/IEC 27001:2022, including Annex A, is a certification standard; Clause 7.5 governs documented information. NIST SP 800-53 Rev. 5 is a control catalogue, binding on US federal systems through separate authority. PCI DSS v4.0.1 binds entities in scope through card-brand and acquirer contracts. GDPR Article 5(1)(e) is a legal requirement where the processing is in scope. This is not a complete list of authorities in the world, and it is not legal advice.
The retention checklist, log-retention, audit evidence repository, continuous collection, and prove-a-control-works pages in this cluster are the deeper reads on the questions this page only frames.
Frequently asked questions
Is this legal advice?
No. It is an operational evidence checklist distilled from the AICPA Trust Services Criteria, ISO/IEC 27001:2022, NIST SP 800-53 Rev. 5, and PCI DSS v4.0.1, with each source labelled by the kind of authority it carries. Which frameworks apply to your organisation, what your contracts require, and how long you must keep records are legal and commercial questions for counsel on your facts.
How much evidence is enough?
Enough to let a reader tie the control to a period, a complete population, and a named person, for every control in your stated control set. Volume is not the measure — a single system-generated export covering twelve months of deploys is stronger than fifty screenshots. Where you cannot evidence a control, record it as a gap rather than assuming it is met.
Do screenshots count as audit evidence?
Sometimes, and they are the weakest common form. A screenshot evidences one moment, usually without a verifiable source or a population, and it is easy to take after the fact. Auditors accept them for configuration facts that do not change often, and generally prefer a system-generated export for anything that needs a period or a population.
Does ShipReady Metrics produce my audit evidence pack?
No. Evidence collection records control-mapped artifacts for starter control subsets, and evidence review lets a named human accept a manual row as met or reject it as a gap, with a timestamp. That is a compliance artifact, not a downloadable evidence binder, not a forensic chain of custody, not a regulator filing pack, and not an auditor's opinion. A named human still owns the audit relationship.
Which category should we build first?
Access, in most cases. It is the category auditors and enterprise customers ask about first, the artifacts are usually already in an identity provider and a source-control system, and the same records feed change management and incident investigation later. Whatever you choose, finish one category end to end before starting a second.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.