Sign in Get started

Free toolkit

SOC 2 Evidence Kit

For a SOC 2 audit, the hard part usually isn’t running the controls. It’s proving you run them. This kit turns "what do I even upload?" into a concrete list: 27 controls and 107 evidence items, mapped to the SOC 2 Trust Services Criteria and grouped into 8 domains.

Download the CSV checklist Track it in Keel instead

Tip: print this page to PDF, or download the CSV and fill in the Status, Owner, and Evidence-link columns as you go.

How to use it

  1. Work domain by domain. For each control, collect the evidence items listed under it.
  2. Aim for current artifacts, dated within your audit window and clearly owned.
  3. Because these controls are crosswalked, most of what you gather here also counts toward ISO 27001, HIPAA, PCI DSS and more. See the crosswalk explorer.

Governance & Risk

Policies, risk management, audit, and oversight that steer the program.

Information security policy

SOC 2 criteria: CC5.3

A board-approved policy set covering information security and the handling of personal data, sized to the scale of the organization and the type of activities it actually carries out, reviewed at least annually and communicated to the workforce. The policy set states the direction the organization is taking on information security - what it commits to, and what it requires of everyone doing work for it - so it sets where the programme is going rather than only recording what it already does. One or more named individuals are designated to coordinate the programme the policies describe - the person in charge of it, named rather than implied, with the designation recorded in writing, made known to the people who need it and kept current as roles change - so there is someone who answers for the policies being carried out and not only for their being published. How far the policies go, and how far the measures they require go, is judged against four things together: the organization’s size, complexity and capabilities; its technical infrastructure and the security capabilities of its hardware and software; what the measures cost; and how likely the risks they address are and how much damage they would do. A policy may be changed at any time, provided the change is documented and is actually put into effect rather than only written down.

  • Approved policy document: The information security policy set with a version, owner, and approval/date.
  • Approval record: Leadership sign-off or meeting minutes approving the current version.
  • Workforce acknowledgements: Records that staff read and accepted the policy (e.g. onboarding sign-off).
  • Annual review note: Evidence the policy was reviewed within the last year.
  • Personal-data policies: The policies and procedures governing how personal data is handled, and something showing they were sized to the organization’s scale and the activities it actually carries out.

Risk assessment & treatment

SOC 2 criteria: CC3.2

A documented process to identify, analyze, evaluate, and treat information security risks on a defined cadence, and again whenever a significant change is proposed or has happened - a new system, a new supplier, a reorganization, a serious incident - so the picture is refreshed by events and not only by the calendar. The process is repeatable: the criteria for accepting risk and for deciding when an assessment is performed are set in advance and applied the same way each time, so repeated assessments produce consistent, comparable and valid results rather than a different answer depending on who ran it. Every risk has a named owner who approves how it will be treated and accepts what is left afterwards. The assessment covers risks and vulnerabilities to the confidentiality, the integrity and the availability of the data the organization holds - all three, not confidentiality alone - and is accurate and thorough enough to be relied on by the decisions taken from it. Treatment brings each risk down to a level that is reasonable and appropriate for this organization, which is the target the process is judged against rather than merely recording that a risk exists. Each assessment and its results are retained as documented information.

  • Risk register: The current register with scored risks, owners, and treatment decisions.
  • Risk methodology: The documented process for identifying, scoring, and treating risk.
  • Treatment plan: Planned or in-progress mitigations for the highest risks.
  • Review cadence: Evidence the register was reviewed/updated on its defined schedule.

Document & records control

SOC 2 criteria: CC5.3

Documented information is created, approved, versioned, and controlled; records are retained and protected for a defined minimum period - measured from the document’s creation OR from the date it last was in effect, whichever is later, so a policy that stayed in force for years does not start its clock on the day it was written - and are available to the people who have to act on the procedures they describe. Documentation is reviewed on a schedule and updated when an operational, environmental or legal change has made the current version wrong. A change forced by law is documented and put into effect promptly, and where that legal change materially affects what the organization has published to individuals about how it handles their data, THAT NOTICE IS REVISED TOO, as part of the same prompt action rather than as a separate task left to whoever owns the notice. Any other change may be made at any time provided the revised version still complies and IS DOCUMENTED BEFORE THE CHANGE TAKES EFFECT - the record precedes the effective date, so a routine that documents changes in arrears does not discharge this.

  • Document register: A controlled list of documents with versions and owners.
  • Revision history: Change history for a controlled document.
  • Retention setting: The defined minimum retention period for policies, procedures and records, and evidence a superseded version from within that period is still held.
  • Availability to implementers: How the people who have to follow a procedure reach the current version - the location, and their access to it.
  • Update on change: A document updated because an operational, environmental or legal change made the previous version wrong, with the dates of the change and the update.

Internal audit program

SOC 2 criteria: CC4.1

A risk-based internal audit program evaluates conformity and effectiveness at planned intervals, and again when an environmental or operational change could have undermined what was last evaluated; each evaluation covers both technical testing and non-technical review of whether the documented policies and procedures are actually being met. The programme itself is written down - how often audits run, what methods they use, who is responsible for them, what each one covers and how it reports - and nobody audits their own work, so a finding is an independent judgement rather than a self-assessment. The results of each audit go to the management responsible for the area audited, and the programme and its results are retained as evidence that it ran.

  • Audit schedule: The planned internal-audit programme for the period.
  • Audit report: A completed internal audit with findings.
  • Technical and non-technical scope: Evidence an evaluation covered both hands-on technical testing and review of whether the documented policies and procedures are actually followed.
  • Change-triggered evaluation: An environmental or operational change, and the re-evaluation it prompted outside the normal schedule.

Management review

SOC 2 criteria: CC4.1

Leadership reviews how the management system is performing at planned intervals and decides what to do about it: what will be improved, and what about the system itself has to change. Each decision leaves the review with a named owner and a date rather than as a sentiment in the minutes, the previous review’s decisions are picked back up at the next one so nothing is decided twice and never done, and the record of the review and its outputs is retained.

  • Management review minutes: Minutes of a leadership review of the management system.
  • Actions & decisions: Follow-up actions assigned from the review.

Delegation of authority & segregation of duties

SOC 2 criteria: CC1.3

Approval authority and spending limits are defined, assigned to named roles, reviewed as the organization changes, and enforced in the systems that execute transactions - so no one person can initiate, approve, record and reconcile the same transaction.

  • Authority matrix: The current delegation-of-authority schedule: what may be approved, up to what limit, by which named role.
  • System enforcement: Configuration showing the approval limits are enforced by the systems that execute transactions, not only stated on paper.
  • Conflicting-duty review: A review of who can initiate, approve, record and reconcile the same transaction, with the conflicts found and how each was resolved or compensated for.

Fraud risk assessment

SOC 2 criteria: CC3.3

A periodic assessment of how fraud could occur here - fraudulent reporting, misappropriation, corruption, and management override of controls - naming the specific schemes considered and the control responding to each.

  • Fraud risk assessment: The dated assessment naming the specific fraud schemes considered - fraudulent reporting, misappropriation, corruption - and the control responding to each.
  • Management override measures: Evidence of the measures aimed at override specifically, such as review of manual journal entries and of significant estimates.

Completeness & accuracy of information used by controls

SOC 2 criteria: CC2.1

Every report, extract, query result, spreadsheet, system-generated listing and third-party statement that a control depends on is identified and listed, and for each one the organization can show why it may be relied upon rather than asserting that it came out of a system. Recorded with the output, not remembered: where the data came from, the parameters, filters and date range that produced it, who produced it and when. Established rather than assumed: that it is COMPLETE, so nothing that belongs in it is missing, and ACCURATE, so what is in it is right - by reconciliation to an independent source, by agreeing a record count or a total back to it, by reperformance of the extract, or by another check stated in advance and evidenced when performed. Information obtained from outside the organization carries the same burden as information it produced itself; its origin is not the reason to trust it. The information reaches the person who has to act on it early enough to be acted on, since data that arrives after the decision it was meant to inform is unusable however accurate it is. The output and the evidence of its check are retained together so the same conclusion can be re-reached later by someone who was not there, and when the underlying system, query or report definition changes, the basis for relying on it is established again rather than carried over.

  • Inventory of information used by controls: The list of reports, extracts, queries, spreadsheets and third-party statements each key control depends on, with the control that consumes each one.
  • Basis of reliance for a sample: For a few of those items: the source, the parameters, filters and date range that produced it, who ran it and when.
  • Completeness and accuracy check: The performed check with its result - a reconciliation to an independent source, a record count or total agreed back, or a reperformed extract - retained alongside the output it was run against.
  • Re-established basis after a change: Where a system, query or report definition changed, evidence the reliance was re-established rather than carried over from the old version.

Access Control

Who can reach which systems and data, and how that access is granted and removed.

Access control policy

SOC 2 criteria: CC6.1, CC6.3

Rules for granting, reviewing, and revoking access to systems and data based on business need and least privilege; anyone who works with sensitive data, or in a place from which it can be reached, is individually authorized for that work or supervised while doing it; and a documented emergency route exists to obtain the data when the normal access path is unavailable, with every use of that route recorded and reviewed afterwards.

  • Access control policy: Rules for granting, reviewing, and revoking access on least-privilege.
  • Role/permission matrix: A mapping of roles to the access each is entitled to.
  • Access request approval: A sample request showing documented approval before access was granted.
  • Authorization or supervision record: For someone who works with sensitive data or in a place it can be reached from, either the record authorizing them for that work or the arrangement under which they are supervised while doing it.
  • Emergency access procedure: The documented break-glass route for obtaining the data when the normal access path is unavailable - who may invoke it and how.
  • Emergency access review: A record of the route being used, and evidence someone reviewed that use afterwards.

User provisioning & deprovisioning

SOC 2 criteria: CC6.2, CC6.3

Joiner/mover/leaver process to grant, change, and promptly remove access across systems, in which every person is issued an account of their own carrying a unique name or number, so an action in a log traces back to one named individual rather than to a shared or generic login. Each person’s right of access is recorded when it is established and reviewed on a schedule thereafter, as well as granted and changed - so what someone holds is a documented position that has been looked at again, not the accumulated residue of past requests - and what may be granted follows the organization’s access authorization rules rather than the judgement of whoever processes the request.

  • Joiner provisioning record: Onboarding/access-provisioning record for a recent new hire.
  • Leaver deprovisioning record: Confirmation access was removed when someone left, dated near their end date.
  • Per-system removal check: Evidence accounts are disabled across each in-scope system on departure.
  • Role-change update: A mover example showing access adjusted when a role changed.
  • Unique identifiers: A user export showing one uniquely identified account per person, and how any remaining shared or generic logins are justified and controlled.

Multi-factor authentication

SOC 2 criteria: CC6.1

Documented procedures verify that a person or system seeking access to sensitive data is the one it claims to be, on every path by which that data can be reached - and multi-factor authentication is the enforced mechanism for remote access, administrative access, and access to sensitive systems and data. The multi-factor mechanism itself is configured so it cannot be bypassed, so the factors it uses are genuinely independent of one another - one factor’s success granting no knowledge of and no route around another - and so access is refused unless every factor required has succeeded.

  • MFA enforcement setting: Configuration/screenshot showing MFA required in the identity provider.
  • Coverage report: An export listing users and their MFA-enrollment status.
  • Admin/privileged MFA: Evidence MFA is enforced on administrative and remote access specifically.

Data Protection & Privacy

Encryption, classification, retention, and individual privacy rights.

Encryption in transit & at rest

SOC 2 criteria: CC6.7

Strong cryptography protects sensitive data in transit over public networks and at rest in storage.

  • Encryption-in-transit config: TLS settings / certificate showing data is encrypted in transit.
  • Encryption-at-rest setting: Storage or database configuration showing at-rest encryption enabled.
  • Key management: How encryption keys are stored, rotated, and access-restricted.

Data classification & handling

SOC 2 criteria: C1.1

Information is classified and handled per its sensitivity, with rules for labeling and protection - including the everyday handling rules that stop it being seen, overheard or picked up by people with no business reading it, so exposure that happens incidentally alongside legitimate work is limited rather than accepted. The handling rules are written to cover disclosure that nobody intended as much as disclosure that somebody chose, they say what an unauthorized disclosure is against the organization’s own privacy and confidentiality rules rather than leaving that to judgement in the moment, and they reach every medium the information travels in - spoken, on paper, on a screen and in a system - because the incidental exposure they exist to limit does not respect the boundary between an administrative, a physical and a technical safeguard.

  • Classification policy: Defined data classes and handling rules for each.
  • Labelling in practice: An example of data labelled/handled per its classification.
  • Data map / inventory: Where sensitive data lives and how it flows.
  • Everyday handling rules: The rules limiting exposure that happens incidentally alongside legitimate work - what is said where, what is left out, what is printed - and how staff are told about them.

Data retention & secure disposal

SOC 2 criteria: C1.2

Data is retained per policy and securely destroyed when no longer needed. The hardware and media that held it reach a defined final disposition at end of life, by a route the organization has decided in advance rather than by whatever happens to the box; and any media that stays in service is cleared of that data before it is reused, reassigned, or passed to anyone else.

  • Retention schedule: Defined retention periods by data type and the disposal method.
  • Secure disposal record: Evidence data/media was securely deleted or destroyed when due.
  • Sanitisation before reuse: For a device or item of media that was reassigned rather than destroyed, evidence the data was removed before it changed hands.

Infrastructure & Operations

Day-to-day security of systems, networks, code, and change.

Logging & monitoring

SOC 2 criteria: CC7.2

Security-relevant events - including successful and failed log-in attempts - are logged, protected, retained, and reviewed for anomalies, and the discrepancies that review finds are reported to the people who act on them. The review runs on a defined cadence and covers the records of system activity as a set - the audit logs, the reports of who accessed what, and the record of security incidents - rather than the log stream alone.

  • Logging configuration: Settings showing security-relevant events are logged and retained.
  • Alerting rules: Configured alerts for anomalous or security-significant activity.
  • Sample alert + triage: An alert that fired with the record of how it was reviewed/actioned.
  • Activity review record: A dated review covering the records of system activity as a set - audit logs, access reports, and the security incident record - showing who reviewed them and what was found.
  • Log-in attempt monitoring: Evidence successful and failed authentication attempts are monitored, and a discrepancy that was reported on.
  • Log retention setting: Evidence logs are kept for the required period.

Vulnerability management

SOC 2 criteria: CC7.1

Regular scanning, prioritization, and remediation of vulnerabilities across systems and applications, fed by current information about threats and weaknesses collected from outside the organization as well as from its own scans - vendor and industry security advisories for the software actually in use, and the threat feeds, bulletins and sector reporting that describe how systems like these are being attacked now - which is gathered continuously rather than at the next scan, evaluated for whether it applies here, and used to decide what is looked for and what is fixed first.

  • Scanner enabled: Configuration showing vulnerability scanning is running across in-scope assets.
  • Findings by severity: A scan export showing findings triaged by severity and their status.
  • Remediation evidence: Before/after or a ticket showing a finding was fixed within SLA.
  • Penetration test report: A recent third-party pen-test report and remediation of its findings.

Malware protection

SOC 2 criteria: CC6.8

Anti-malware controls prevent, detect, and respond to malicious software on endpoints and servers, and detections are reported to the people who act on them. The mechanism is kept live rather than merely installed: signatures, definitions and detection engines update automatically as the vendor issues them rather than on someone remembering to apply them, what it detects and what it does about it is logged, and it runs where an ordinary user cannot switch it off, uninstall it or exclude their way around it - only a documented, authorized change may disable it, and then for a stated period.

  • Endpoint protection deployed: Console/export showing anti-malware is installed and active on endpoints.
  • Coverage report: A list of devices confirming protection is enrolled and up to date.
  • Detection handling: A sample detection and how it was quarantined/resolved, including who it was reported to.

Change management

SOC 2 criteria: CC8.1

Changes to systems and software are requested, reviewed, tested, approved, and tracked.

  • Change process: The documented workflow for authorizing, testing, and approving changes.
  • Sample change with approval: A production change showing review/approval before release.
  • Peer review / CI checks: Pull-request review or pipeline gates enforcing the process.

Secure software development

SOC 2 criteria: CC8.1

Secure coding, review, and testing practices across the development lifecycle.

  • Secure development policy: Secure-SDLC standards developers follow.
  • Code review evidence: Pull-request reviews / branch protections enforcing review.
  • Pipeline security checks: SAST/dependency/secret scanning wired into CI.

Network security controls

SOC 2 criteria: CC6.6

Firewalls/segmentation and network controls restrict traffic to and from sensitive environments.

  • Network controls config: Firewall/security-group rules restricting traffic to what’s needed.
  • Segmentation: Evidence sensitive environments are isolated from general access.
  • Rule review: A periodic review of network/firewall rules.

Resilience & Continuity

Backups, continuity, and incident response for when things go wrong.

Backups

SOC 2 criteria: A1.2

Regular, tested backups of critical data and systems with defined retention, each one a RETRIEVABLE EXACT COPY of the data it protects - complete and restorable, not a partial or lossy snapshot - including a copy taken before equipment holding that data is moved.

  • Backup configuration: Settings showing what is backed up and on what schedule.
  • Successful backup log: Recent job history confirming backups completed.
  • Restore test: Evidence a restore was performed and verified.
  • Pre-move copy: For a recent equipment move, the exact retrievable copy taken beforehand - or the procedure requiring one, with a move it was applied to.

Business continuity & disaster recovery

SOC 2 criteria: A1.2, A1.3

BC/DR plans with defined RTO/RPO, tested periodically AND REVISED on what the testing finds and on what has changed since, to restore service after disruption - including how the critical processes that protect sensitive data keep running while the organization is operating in emergency mode, and an assessment of how critical each application and data set is, which is what sets those recovery targets and the order in which things come back.

  • BC/DR plan: The documented continuity and disaster-recovery plan with roles and RTO/RPO.
  • Plan test / tabletop: Results of a recent BC/DR exercise or failover test.
  • Review record: Evidence the plan was reviewed/updated on its cadence.
  • Emergency-mode operation: The part of the plan that keeps the processes protecting sensitive data running while the organization is operating in emergency mode - not the part that restores service afterwards.
  • Criticality analysis: The assessment ranking applications and data sets by criticality, and evidence the recovery targets and recovery order were set from it.

Incident response

SOC 2 criteria: CC7.3, CC7.4

A documented, tested plan to detect, triage, contain, remediate, and communicate security incidents, and to mitigate - so far as is practicable - the harmful effect of a use or disclosure of personal data the organization knows breached its own policies or the law. Each incident is recorded together with its outcome - what happened, what was done about it and how it ended - as a record of that incident, which is a different artifact from the plan being documented. The mitigation duty runs to violations by the organization itself AND to violations by the processors, vendors and other parties handling that data on its behalf: the plan reaches an incident somebody else caused with the organization’s data, so learning of one triggers the same containment and remediation as an incident inside its own walls rather than a request that the other party deal with it. Where an incident carries a duty to tell someone outside the organization, the plan discharges it on the clock the applicable law sets rather than whenever the investigation happens to conclude: whether an incident is notifiable is decided against written criteria rather than argued after the fact, the regulator or supervisory authority is notified inside the deadline that regime states, the people whose data is affected are told where the risk to them warrants it, and where a deadline is missed the notification itself explains the delay instead of passing over it.

  • Incident response plan: The documented plan with severities, roles, and notification steps.
  • IR exercise: A tabletop or simulation with dated results and follow-ups.
  • Incident record: A handled incident (or "no incidents" attestation) with the post-incident review.
  • Mitigation of a data violation: For a known improper use or disclosure of personal data, what was done to limit the harm to the people affected, and how far it was practicable to go.

Third-party Risk

Oversight of the vendors and suppliers you depend on.

Third-party / vendor risk management

SOC 2 criteria: CC9.2

Due diligence, contractual safeguards, and ongoing monitoring of vendors that handle your data: the agreement obliges the vendor to comply in its own right with the security requirements that apply to it - an absolute standard, not a promise to match whatever you happen to do - to pass those obligations down to any subcontractor it brings in BY ENTERING INTO a contract or equivalent written arrangement with that subcontractor rather than by merely requiring equivalent practice of it, and to report to you, within a stated time, security incidents it becomes aware of and confirmed breaches of your data. Where a contract is not the instrument available, an equivalent written arrangement carrying the same obligations discharges the duty. The same obligations, together with the separation that keeps a related organization out of data it is not entitled to, are written into the governing document of any other arrangement that puts your data in the hands of a sponsor, parent, affiliate or plan. Diligence is not confined to security where the relationship warrants more: for suppliers significant enough to matter, the organization states the standards of conduct it expects of them - how they behave commercially and how they treat the environment around their operations - and screens candidates and incumbents against those stated expectations as part of the same selection and monitoring cycle, rather than accepting a signature on a code as evidence of it.

  • Vendor inventory: A list of third parties with data access and their risk tier.
  • Vendor risk review: A completed assessment/questionnaire for a key vendor.
  • Vendor reports on file: A vendor's SOC 2 / ISO cert or security summary collected on review.
  • Contract safeguard clauses: The clauses in a signed vendor agreement requiring equivalent safeguards, flow-down to subcontractors, and incident and breach reporting to you within a stated time.
  • Related-organization arrangement: Where a sponsor, parent, affiliate or plan holds the data, the governing document carrying the same obligations and the separation that keeps that organization out of what it is not entitled to.

People & Culture

Training, HR security, competence, and workforce practices.

Security awareness training

SOC 2 criteria: CC1.4

Ongoing security and data-handling awareness training for all personnel, with completion tracking, and periodic security updates - reminders, bulletins and alerts - issued to the workforce between training cycles. New joiners are trained within a defined period of starting, anyone whose work is affected is retrained within a defined period after a material change to the policies or procedures, and every completion is recorded.

  • Training completion report: Records showing staff completed security-awareness training.
  • Course content: The material/curriculum covered.
  • Security reminders issued: Examples of the periodic updates sent between training cycles - a bulletin, alert, or notice - with the date and audience.
  • Phishing simulation: Results of a simulated phishing exercise, if run.
  • New-joiner training timing: For a recent joiner, the gap between their start date and their training completion, against the period the organization committed to.
  • Retraining after a change: A material change to the policies or procedures, and the record of the affected people being retrained after it.

Personnel security (HR)

SOC 2 criteria: CC1.4

Background screening, confidentiality agreements, and onboarding/offboarding security steps. Before a person is given access to sensitive data, and again whenever their role changes, a documented determination is made that the access their work calls for is appropriate to it - the screening informs that decision but is not the decision. What screening may ask is itself bounded: enquiries about a candidate’s health, disability or medical history are not made, and medical examinations are not required, before a conditional offer of the role has been made, and where such enquiries or examinations are made after an offer they are applied to everyone entering that role rather than to the individuals somebody chose to ask. Access is ended when their employment, or any other arrangement under which they worked for the organization, comes to an end, and whenever that determination says they should no longer hold it.

  • Background check record: Evidence pre-employment screening was performed where allowed.
  • Signed acknowledgements: Confidentiality/acceptable-use agreements signed by staff.
  • Onboarding checklist: A completed onboarding record covering security steps.

Physical & Environmental

Facilities, physical security, and environmental commitments.

Physical security

SOC 2 criteria: CC6.4

Physical access to facilities and equipment holding sensitive data is restricted and monitored, and a person’s access is validated against the role or function that justifies it rather than only logged; visitors are controlled as a case of their own, and so is access to software programs held for testing and revision. The facility and the equipment in it are safeguarded against tampering and theft as well as against unauthorized entry. The people who have to reach the site and the equipment when a continuity or recovery plan is invoked can still get in, by a route that is planned rather than improvised; and repairs and modifications to the physical security components of a facility - doors, locks, walls, and the hardware that controls entry - are recorded.

  • Physical security policy: Rules for facility access and protecting physical assets.
  • Access controls: Badge/visitor logs or entry-control configuration.
  • Provider attestation: For cloud-hosted orgs, the data-center provider’s physical-security report.
  • Contingency access procedure: The planned route by which recovery staff reach the site and the equipment when a continuity or recovery plan is invoked.
  • Maintenance record: The log of repairs and modifications to security-relevant physical components - doors, locks, walls, entry hardware - with dates.
Start free: collect this once, comply everywhere