The ISO 27001 Evidence Checklist for SaaS and Fintech

Most ISO 27001 audits are not lost on the design of your controls. They are lost on evidence. You wrote the policy, you run the review, you patch the servers - but when the auditor asks you to prove it, the record is missing, stale, or scattered across three tools. This guide walks the control areas auditors sample most, explains the difference between weak and strong evidence, and shows you what to have ready before the assessor arrives.

What "evidence" actually means

Evidence is a record that a control operated, at a specific time, for a specific thing. A policy states intent. Evidence proves the intent was carried out. An auditor is not impressed that you have an access control policy. They want to see that a named person reviewed access on a real date and that something happened as a result.

Weak evidence is a document that describes what you say you do. Strong evidence is a dated, attributable artefact produced by the control running in normal operation: a ticket, a signed review, an export with a timestamp, an approval in a tool. The best evidence is a by-product of work you already do, not something manufactured the week before the audit.

Auditors sample. They will not read every record. They pick a period, ask for the population, and select a handful of items to test. So your evidence must be complete for the period, retrievable on request, and consistent between what the policy claims and what the record shows.

What to have ready

• A short index that maps each Annex A control to where its evidence lives.
• A named owner for each control area.
• An agreed audit period, and confidence that records cover the whole of it.

Access reviews: joiners, movers, leavers

This is the single most sampled area, and the most commonly failed. Auditors care about the full identity lifecycle, not just the current state of who has access.

Weak evidence is a screenshot of your current user list. It shows a moment, not a process. It does not prove that access was granted on approval, changed when someone moved teams, or removed when they left. Strong evidence shows the lifecycle: a ticket approving access for a new joiner, a record of entitlement change when someone moved role, and a leaver record with timestamps proving deprovisioning across your critical systems.

The leaver case is where audits fail. The auditor picks a person who left three months ago and asks you to prove their access was removed from your identity provider, your cloud console, your code repository, and your production database. If any account is still live, that is a finding. Periodic access reviews matter too: a quarterly review where an owner confirmed each user still needs their access, with any removals actioned and evidenced.

What to have ready

• Joiner approval records tied to role.
• Mover records showing entitlements changed on transfer.
• Leaver records with deprovisioning timestamps across all critical systems.
• Periodic access review sign-offs, with resulting removals evidenced.

Supplier and subprocessor reviews

You are responsible for the security of the vendors that touch your data. For SaaS and fintech, that means cloud providers, payment processors, and every subprocessor in the chain.

Weak evidence is a list of vendors in a spreadsheet. Strong evidence is a record that each supplier was assessed at onboarding and reviewed on a cycle appropriate to its risk. That means holding their current certification or SOC 2 report, a dated review of that report, contractual clauses covering security and data handling, and a note of any issues raised and tracked.

Auditors will ask how you decide which suppliers get more scrutiny. Show risk-based tiering: a payment processor holding cardholder data gets deeper review and a shorter cycle than a marketing tool. Show that reviews actually happened on schedule, not that they were intended.

What to have ready

• A supplier inventory with risk tiers.
• Current assurance reports for critical suppliers, with dated reviews.
• Contracts with security and data protection terms.
• Records of issues raised with suppliers and their resolution.

Change and release management

Auditors trace changes from request to production. The clean chain is ticket, review, test, deploy - and they will sample real changes to see if that chain held.

Weak evidence is a claim that all changes go through review. Strong evidence is a sampled change where you can show the originating ticket, the peer review or approval, evidence it was tested, and a deploy record linking back to the ticket. The link between the code that shipped and the approval that authorised it is the point of the control.

Expect the auditor to pick a change from your deploy history and work backwards. If they cannot trace it to an approval and a test, the control failed for that item. Emergency changes need their own path: a documented process, and retrospective review evidence showing they were caught up after the fact.

What to have ready

• Change tickets linked to code and deploys.
• Peer review or approval records on the change.
• Test evidence for sampled changes.
• Emergency change process with retrospective approvals.

Secure development and the SDLC

Security controls belong inside the development process, not bolted on. Auditors look for evidence that security requirements, review, and testing are part of how you build.

Weak evidence is a secure coding policy nobody references. Strong evidence is security embedded in the pipeline: code review required before merge, static analysis or dependency scanning running in CI with results actioned, secrets management in place, and separation between development and production. For fintech, expect questions about how security requirements are captured for features that handle money or sensitive data.

Show the tooling output. A scanner that runs but whose findings are never triaged is weak evidence. A scanner whose critical findings are ticketed and fixed within a defined window is strong.

What to have ready

• Enforced code review before merge.
• CI scanning output with triage and remediation records.
• Secrets management and environment separation evidence.
• Security requirements captured for sensitive features.

Incident management

Whether or not you had a major incident in the period, you must prove the process works.

Weak evidence is an incident response plan and nothing else. Strong evidence is a record of real incidents - even minor ones - showing detection, classification, response, resolution, and lessons learned. If you genuinely had no incidents, evidence a test or tabletop exercise that ran the process end to end.

Auditors look for the loop closing. An incident that was resolved but produced no corrective action or lesson suggests the process stops at firefighting. Show that at least some incidents fed improvements back into controls.

What to have ready

• An incident register with dates and severity.
• Records showing detection through to resolution for sampled incidents.
• Post-incident reviews and resulting actions.
• A tabletop or test if no real incidents occurred.

Vulnerability management

Auditors want to see that you find, prioritise, and fix vulnerabilities within defined timeframes.

Weak evidence is a single scan report. Strong evidence is a running process: regular scans, a severity-based remediation policy with target timeframes, and records showing vulnerabilities were fixed within those windows. Penetration test reports and evidence that findings were remediated carry weight, especially for fintech.

The auditor will check your timeframes against reality. If your policy says critical vulnerabilities are fixed in seven days and your records show a critical open for two months, that mismatch is the finding - not the vulnerability itself, but the broken commitment.

What to have ready

• Regular scan results over the period.
• A remediation SLA by severity.
• Records proving fixes met the SLA, with exceptions justified.
• Penetration test reports and remediation evidence.

Backups and restore tests

Having backups is not the control. Proving you can restore from them is.

Weak evidence is a backup configuration screen showing jobs are scheduled. Strong evidence is a dated restore test where you actually recovered data and confirmed its integrity. Backups that have never been tested are, from an auditor's view, unproven.

Show a restore test performed within the period, who ran it, what was recovered, and that it worked. This is a fast finding to receive and an easy one to prevent.

What to have ready

• Backup schedule and scope.
• A dated, successful restore test with a named owner.
• Confirmation of data integrity after restore.

The risk register

The risk register is the spine of your ISMS. Auditors read it closely.

Weak evidence is a risk register created once and never touched. Strong evidence is a living register: risks identified with owners, assessed for likelihood and impact, treated with clear decisions, and reviewed on a cycle. Dates matter. A register last updated a year ago signals the risk process stopped.

Expect the auditor to trace a risk through to its treatment and then to the control that addresses it, and back to the Statement of Applicability. The register should connect to real activity, not sit in isolation.

What to have ready

• A current register with owners, scores, and treatment decisions.
• Evidence of periodic review with dates.
• Traceability from risk to control to Statement of Applicability.

The Statement of Applicability

The SoA states which Annex A controls apply, which do not, and why.

Weak evidence is a template SoA with generic justifications. Strong evidence is an SoA that reflects your actual environment, with real reasons for any exclusions and current implementation status per control. Auditors cross-check the SoA against what they see on the ground. If the SoA marks a control as implemented but you cannot show it operating, that gap is a finding.

What to have ready

• A current SoA aligned to your risk treatment.
• Clear, specific justifications for inclusions and exclusions.
• Implementation status that matches reality.

Management review

Leadership must demonstrably engage with the ISMS.

Weak evidence is a claim that management is committed. Strong evidence is minuted management review meetings held on a defined cadence, covering the required inputs: audit results, incidents, risk status, objectives, and resourcing, with decisions and actions recorded. Auditors check attendance, frequency, and whether actions from prior reviews were followed up.

What to have ready

• Management review minutes covering the required inputs.
• Recorded decisions and actions with owners.
• Evidence prior actions were closed.

Internal audit

You must audit your own ISMS before the external assessor does.

Weak evidence is an internal audit report with no findings and no depth. Strong evidence is an internal audit programme covering the ISMS over time, conducted with appropriate independence, that actually found things and drove them to closure. An internal audit that finds nothing usually signals it was not rigorous.

What to have ready

• An internal audit plan and schedule.
• Audit reports with findings and evidence of independence.
• Findings tracked through to closure.

Corrective actions

When something goes wrong, the auditor wants to see it fixed properly, not just patched.

Weak evidence is a nonconformity marked closed with no detail. Strong evidence is a corrective action record that captures the issue, the root cause, the fix, and verification that the fix worked. Root cause is the part teams skip. Treating the symptom without the cause invites the same finding again.

What to have ready

• A corrective action log linked to findings.
• Root cause analysis for each action.
• Verification that the action was effective.

Business continuity

Auditors want confidence that you can keep operating and recover from disruption.

Weak evidence is a business continuity document that has never been exercised. Strong evidence is a plan supported by a test: a scenario walkthrough or a real recovery exercise, dated, with participants and outcomes recorded. Tie this to your backup restore tests and incident process so the picture is coherent.

What to have ready

• A continuity plan with defined recovery objectives.
• A dated test or exercise with recorded outcomes.
• Lessons fed back into the plan.

Evidence readiness checklist

Before the audit, confirm you can produce, on request and for the agreed period:

• Access lifecycle records: joiner approvals, mover changes, leaver deprovisioning, and periodic reviews.
• Supplier assessments and dated reviews for critical vendors.
• Change records traceable from ticket to review to test to deploy.
• SDLC evidence: enforced code review, CI scan output with triage.
• Incident register with resolution and lessons, or a tabletop if none occurred.
• Vulnerability scans and remediation within SLA.
• A dated, successful restore test.
• A current, reviewed risk register with owners.
• An SoA that matches your environment.
• Management review minutes with actions.
• Internal audit reports with findings closed.
• Corrective actions with root cause and verification.
• A business continuity plan with a dated test.

Make your evidence findable

Good evidence that no one can find fails the audit anyway. The fix is boring and effective: one place, dated, owned.

Keep an evidence index that maps each control area to where its records live. Give every artefact a date and a named owner. Where evidence is a by-product of a tool - tickets, CI output, access exports - know how to pull the export quickly and confirm it covers the period. Auditors read hesitation as weakness. Being able to retrieve any record in minutes signals a system that runs, not one assembled for show.

Bottom line

ISO 27001 rewards operational discipline, not documentation volume. The organisations that pass cleanly are the ones whose controls produce evidence as a natural output of daily work, kept in one findable place with clear owners and current dates. Everything above is achievable well before an assessor arrives, if you know what strong evidence looks like and where the gaps are.

If you want a clear read on where your evidence stands before you commit to an audit, a Kellwick readiness review will map your controls to the evidence auditors sample, flag the gaps, and give you a practical plan to close them.