neart.ai
EcosystemStoryHow We BuildPricingBlog
Try Inspected →
neart.ai
EcosystemStoryHow We BuildBlog

Ní neart go cur le chéile

A SaltCore Group Limited company

© 2026 neart.ai · SaltCore Group Limited. All rights reserved.

Compliance & Security

What Evidence Do Auditors Actually Ask For in SOC 2 and ISO 27001?

1 February 20254 min read

## The short answer


In both SOC 2 and ISO 27001, auditors ask for **evidence that your controls actually operated** — not just policies stating that they should. The most commonly requested evidence falls into a handful of categories: access management records, change management records, monitoring and logging, vulnerability and patch management, vendor management, risk assessments, and incident records. The single biggest difference between a smooth audit and a painful one is whether you collected this evidence *continuously* or tried to reconstruct it at the end.


## Policies are necessary but not sufficient


A written policy says what you intend to do. Evidence shows you did it. Auditors care about the gap between the two. A beautifully worded access-control policy means little if you cannot produce the quarterly access reviews it promises. So while you do need documented policies, expect most of an auditor's effort to focus on operational proof.


## The evidence auditors most commonly request


### Access management


- Lists of who has access to key systems, and at what privilege level.

- Records of periodic access reviews (and the de-provisioning that followed).

- Evidence that joiners, movers, and leavers were handled — access granted on hire, changed on role change, revoked on departure.

- Multi-factor authentication enforcement.


### Change management


- Records that code or infrastructure changes were reviewed and approved before deployment.

- Links between changes and their tracking tickets.

- Evidence that production changes followed your stated process.


### Monitoring and logging


- Proof that logging is enabled across relevant systems.

- Evidence that alerts are generated and that someone responds to them.

- Records of how anomalies were triaged.


### Vulnerability and patch management


- Vulnerability scan results.

- Evidence that findings were remediated within your stated timeframes.

- Patch deployment records.


### Vendor and third-party management


- An inventory of subprocessors and critical vendors.

- Evidence you assessed their security (for example, by reviewing their own SOC 2 or ISO 27001 status).

- Contracts with appropriate security and data-protection clauses.


### Risk and governance


- A current risk assessment (central to ISO 27001, valued in SOC 2).

- Records of management reviews and internal audits.

- For ISO 27001, a maintained Statement of Applicability.


### Incident management


- Your incident response process.

- Records of incidents, how they were handled, and lessons learned (even minor ones demonstrate the process works).


## Why continuous collection wins


For SOC 2 Type II and for ISO 27001 surveillance audits, evidence must span a period. Auditors *sample* across that window — they might ask for the access review from a specific month, or three change tickets from a particular quarter. If those artefacts were never captured at the time, you cannot produce them honestly afterwards.


This is why the night-before-the-audit screenshot scramble is both stressful and risky. Reconstructed evidence is weaker, sometimes impossible, and erodes auditor confidence.


## A practical preparation checklist


1. **Map controls to evidence** — for each control, know exactly what artefact proves it ran and where that artefact lives.

2. **Automate capture** where possible — pull access lists, scan results, and logs automatically rather than manually.

3. **Set a cadence** — schedule access reviews, risk reviews, and management reviews, and keep records of each.

4. **Centralise storage** — keep evidence in one organised place, not scattered across inboxes and chat threads.

5. **Timestamp everything** — auditors care *when* something happened, not just that it did.

6. **Run a dry run** — internally sample your own evidence the way an auditor will, and fix gaps before the real audit.


## Common evidence pitfalls


- **Screenshots with no timestamp or context** — they prove little.

- **Policies dated just before the audit** — they suggest the control did not exist during the period.

- **"We always do this" with nothing to show** — verbal assurance is not evidence.

- **Evidence scattered across personal accounts** — if the only copy is in someone's inbox, it effectively does not exist.


## Where tooling helps


Continuous evidence collection is precisely what compliance automation exists to solve. Enterprise-grade tooling — the kind neart.ai builds — connects to your systems, gathers access, change, and monitoring evidence on a schedule, timestamps it, and maps it to the relevant controls. That turns audit preparation from a frantic reconstruction into a routine export.


## Takeaway


Auditors trust evidence, not intentions. Decide upfront what artefact proves each control, capture it automatically and on a fixed cadence, and store it centrally with timestamps. Do that from day one and your SOC 2 or ISO 27001 audit becomes an export, not an ordeal.

Related posts

Compliance & Security

Does GDPR Apply to My Small Business? A Plain-English Test

Compliance & Security

The Six GDPR Lawful Bases: How to Choose the Right One

Compliance & Security

How to Handle a Data Subject Access Request, Step by Step