Implementing ISO 27001 for regulated fintech

ISO 27001 is the most-asked-for certification in regulated B2B fintech sales cycles. A working ISO 27001 ISMS is also the structural backbone that DORA, SOC 2, PCI DSS v4, and NIST CSF programmes can plug into without each needing its own parallel evidence trail.

This article walks the 26-week path I’ve delivered multiple times in fintech contexts (anonymised), with particular attention to the operating model that survives the certification cycle and remains useful in years 2, 3, and beyond.

The 26-week path

Weeks 1-4 — Scoping

The most consequential weeks. Two questions to answer:

• What’s in scope? The certification boundary. Too wide and the programme becomes unmanageable; too narrow and the certificate isn’t sales-useful.
• What’s the scope statement? The literal one-sentence statement that goes on the certificate.

Practical approach for fintech:

• Scope the platform that delivers your regulated product (e.g. “the payments platform”) plus the security operations supporting it
• Out of scope (initially): corporate IT, marketing systems, internal HR
• Document the scope decision in a Statement of Applicability that can be reviewed by your auditor before you build the controls

Outputs of this phase:

• Scope statement (signed off by the management body)
• Initial risk register (top 25 risks; will grow)
• Statement of Applicability (one row per Annex A control: applicable / not applicable + rationale)
• 26-week project plan with named owners

Weeks 5-16 — Control design and implementation

This is the bulk of the work. Three principles:

Build with the team that operates the control

Don’t build a control “for” engineering; build it with them. Their input on what’s actually achievable in the platform shapes what the control should be. Their commitment to operating it shapes whether it survives Q4 of the surveillance cycle.

Generate evidence as a side effect of operating the control

Every control should produce evidence at run-time, not as a quarterly collection sprint. Examples:

• Access reviews: an automated job emails the manager monthly with the list of permissions; the response is the evidence
• Vulnerability management: the scanner output IS the evidence; just retain it
• Change management: the PR + signed commit + deploy log IS the evidence

If your evidence requires someone to manually compile it for the auditor, the control isn’t built right.

Use the auditor’s preferred format

Most auditors will tell you, if you ask: “We prefer evidence in this shape.” Build to that shape from day one. The first audit goes materially smoother.

Weeks 17-22 — Internal audit

Full dry-run with structured findings and remediation plan. Common breakdowns:

• Access reviews completed but not actioned
• Risk register entries not linked to a treatment owner
• Evidence retention shorter than the auditor expects
• Management body review of ISMS not formally minuted

23 minor findings is normal in a well-run programme. Closing them before Stage 1 is the minimum bar.

Weeks 23-25 — Stage 1 + Stage 2

Stage 1 is essentially a documentation review. Stage 2 is the operational audit. Both you attend.

Practical tips:

• Hold pre-meet with the auditor to align expectations
• Have the lead audit-response writer in the room for every session
• Take notes throughout; respond same day
• For each finding, propose a remediation timeline at the closing meeting (auditors much prefer this to “we’ll get back to you”)

Week 26 — Certification

Certificate issued. Surveillance cycle starts.

The operating model that survives

Most certifications I’ve seen rot during year 2-3 because the programme didn’t transition to BAU cleanly. Three patterns that prevent rot:

Pattern 1 — quarterly ISMS reviews on the management calendar

The ISO standard requires “management review” at planned intervals. The standard is silent on cadence; pick quarterly. Put it on the management body’s calendar. Don’t move it.

Pattern 2 — control owner accountability built into role descriptions

Every applicable control has a named owner in the Statement of Applicability. That ownership goes into the role description, not just the SoA. The control owner’s annual objectives include “maintaining their ISO control set.”

Pattern 3 — surveillance audits prepared monthly, not annually

Each month, the GRC lead spends one day on “surveillance preparation”: reviewing one-twelfth of the controls. By month 12 the entire programme has been touched. The annual surveillance audit is a formality.

Mapping to other frameworks

A working ISO 27001 ISMS gives you, for free, a substantial chunk of:

• SOC 2 Type 2 — most ISO 27001 controls map directly to SOC 2 Trust Services Criteria
• PCI DSS v4 — the ISMS spine + ISO 27001 control governance satisfies the management framework requirements; the technical PCI controls layer on top
• DORA — Articles 5-15 (risk management framework) align with ISO 27001 clauses 4-10; Articles 17-23 (incident reporting) need additional capability but reuse the ISMS governance
• NIS2 — similar mapping at the management framework level

The reverse isn’t true: a SOC 2 Type 2 doesn’t give you ISO 27001 without significant additional work. ISO 27001 is the load-bearing framework; treat it that way.

What goes wrong

Three failure modes:

Failure 1 — over-scoping in week 1

The team includes corporate IT in scope “to be safe”. 26 weeks becomes 52. Fix: ruthlessly narrow scope at week 1. You can always expand at recertification.

Failure 2 — evidence generated manually

The audit is a 4-week evidence-collection sprint each year. Fix: re-engineer controls so evidence is a run-time side effect.

Failure 3 — certificate becomes a sales asset; ISMS rots

The team checks the box and forgets the operating model. Year 3 recertification finds widespread non-conformity. Fix: the patterns above (quarterly review, owner accountability, monthly surveillance prep).

How to know you’re getting it right

Three signals:

• Internal audit findings count trends down across cycles
• Time from new control owner appointment to “operating effectively”: weeks, not months
• Auditor questions decrease per cycle (predictability is a positive signal of programme health)

What to do tomorrow morning

If you’re not yet ISO 27001 certified and considering the path:

1. Write your scope statement on a single page. Be ruthless.
2. List the top 25 risks within that scope.
3. Estimate the calendar: 26 weeks of focused work + ~£15-30k of external auditor cost (UKAS-accredited body) for first cycle.
4. Decide who runs the programme — internal lead with vCISO support is a common shape for fintech (see our vCISO service for the model).

If you’re already certified and worried about year 2-3 rot, the three patterns under “operating model that survives” are the place to start.

---

This article is part of our DORA readiness pillar (ISO 27001 is foundational for DORA programmes). For hands-on ISO 27001 delivery, see our GRC and audit readiness service.