ISO 27001 for vendors selling to banks

Does a bank vendor need ISO 27001 for a bank contract?

No supplied source requires ISO 27001 by name for a vendor serving a bank, so the honest answer is that it depends on the customer, the contract and the jurisdiction. A bank or financial customer that asks for ISO 27001 or a security assessment during due diligence is usually asking for evidence that your controls are independently checked. The certificate is only one form of that evidence. The proposed US community bank guidance in the Federal Register treats ISO reports as one kind of independent assessment, alongside SOC 2 reports and other industry assessments, when a bank assesses a cybersecurity vendor. Under the EU Digital Operational Resilience Act (DORA), financial entities may contract only with providers that comply with appropriate information security standards, so a bank under DORA will want to see which standard you meet and how you prove it.

Before you commit to certification, confirm with the customer exactly what it will accept. Ask whether it names ISO 27001 in its questionnaire or contract, whether it accepts a SOC 2 report or a PCI DSS attestation instead, and whether it expects a certificate, an audit report or both. Ask which jurisdiction governs the contract, since a US community bank, a bank supervised under DORA and a non-EU bank operate under different rules. Also confirm whether the customer wants a certificate for the whole company or only for the services it buys, because that choice determines the scope you will need to defend.

Check the certificate itself before you rely on it. An accredited certification body issues the ISO 27001 certificate, not your implementation partner, and it must name the standard and its issue status and carry a scope that is not misleading. Verify it in the IAF CertSearch database, which ISO's certification page describes as the place to check accredited certificates. Treat a certificate issued by a body that cannot show accreditation as a document the bank will reject during review.

What banks ask for beyond an ISO 27001 certificate

A certificate tells a bank that an ISMS exists and was audited against the standard. Banks also need to know how the vendor performs under contract, how it depends on other providers and how it recovers from failure. The six areas below are where those questions usually land, and each one needs evidence that sits outside the certificate.

Audit and inspection rights

Under DORA Article 30(3), providers of services supporting critical or important functions must grant the customer, its appointed third parties and the competent authority unrestricted access, inspection and audit rights. An ISO 27001 certificate does not grant these rights. The vendor prepares a current audit access procedure, a list of prior audit reports and named contacts, while the bank decides the audit scope, frequency and contract wording.

Sub-outsourcing and supply chain disclosure

Banks ask which subcontractors, cloud regions and hosting providers touch their data or services, and how changes to that chain are notified. The ISO 27001 supplier controls cover some of this, but the bank needs a current register that names each subprocessor and its role. The vendor maintains the register and change records. The bank decides which subcontracting it accepts and what approval it requires before a change.

Incident notification timelines

Banks must meet their own incident reporting duties, so they need vendor notification fast enough to meet those clocks. The vendor documents its incident classification, escalation contacts and the information it will provide at each stage. The Statement of Applicability and incident management records show the process exists, but the notification window itself is a contract term. The bank sets the window, and the vendor confirms it can meet it in tested exercises.

Tested business continuity

DORA Article 30(3) requires providers of critical or important services to implement and test business contingency plans. A documented continuity plan is not enough for a bank reviewer, who will ask for the last test date, the scenarios covered and the recovery results. The vendor prepares test records and corrective actions. The bank decides which recovery objectives are acceptable and whether the vendor's test results meet them.

Data location and exit or portability

Banks ask where customer data is stored and processed, and how it is returned or deleted when the contract ends. The vendor documents storage locations, backup locations and the export formats it supports. Exit planning needs a tested procedure, not only a clause. The bank decides the acceptable jurisdictions and exit timelines. Confirm in writing which data categories the exit procedure covers.

Penetration test and resilience testing results

Banks often ask for recent penetration test reports and remediation status, and for participation in threat-led testing where it applies. Under Article 30(3), providers must participate fully in the customer's threat-led penetration testing. The vendor prepares its test reports, remediation tracking and scope statements. The bank decides which tests it relies on and whether it runs its own. Confirm that the test scope covers the services the bank actually buys.

How banks check the certificate and its scope

A bank's third-party team will want to confirm two things before it relies on an ISO 27001 certificate: that the certificate is genuine and in force, and that its scope covers the service the bank is buying. Under ISO/IEC 17021-1 clause 8.2.2, as cited in European Accreditation FAQ 36.10, a certificate must name the management system standard including its issue status, its scope must not be misleading or ambiguous, and under an IAF decision it may not reference standards outside the scope of accreditation. Read the certificate itself against those points. Check the edition named (ISO/IEC 27001:2022 or a remaining 2013 certificate, noting the 31 October 2025 expiry for 2013 certificates under IAF MD 26:2023), the issue status, the issuing body, and the expiry or next surveillance date.

Verify the certificate independently rather than relying on a copy supplied in a questionnaire response. ISO points to the IAF CertSearch database, which can be searched individually, in bulk or through an API, and to contacting the certification body or accreditation body directly. Since 1 January 2026 Global ACI has taken over the roles of IAF and ILAC, so confirm the current accreditation body reference on the certificate. Ask the vendor to confirm the certification body's name and accreditation status in writing, and record the search date, because a certificate can be suspended or withdrawn after it was first checked.

The scope is where most gaps appear. Confirm that the certified scope names the service the bank buys, such as a specific platform, hosting environment, support desk or data processing function, and not only the head office or a general statement about the company. If the service runs from a site, a cloud region or a subcontracted facility outside the certified scope, ask how that dependency is handled in the Statement of Applicability and the supplier controls. A scope that is vague, or that cites standards beyond the accredited scope, should be raised with the vendor before the bank accepts the certificate as assurance for that service.

How a vendor gets its ISO 27001 evidence ready for a bank review

This sequence takes a vendor from a bank-facing ISMS scope to a certificate that a bank's due diligence team can verify, then keeps the evidence current through surveillance audits and the questionnaires and audit requests that follow. Timing at each phase depends on the certification body, the scope and the vendor's readiness, so confirm the schedule in writing before work starts.

Scope the ISMS around the bank-facing service
Start by naming the service a bank buys, the systems, data, sites and staff that support it, and the suppliers the service depends on. Leadership approves the scope and the organization writes it down, because the certificate will name this scope and a bank will test whether it covers the service in its contract. DeployOpen can help map the technical boundary, but the organization owns the decision. Done means a written scope statement that a bank's risk team could read without confusion, along with a draft Statement of Applicability linked to it.
Complete the risk assessment and treatment plan
The organization identifies information security risks to the scoped service, rates them using its own method, and selects treatment decisions that feed the Statement of Applicability. Implementation partners can prepare registers, asset inventories and risk workshops, while the risk owners sign off on acceptance. Done means a risk register, a treatment plan and a Statement of Applicability that explains, for each Annex A control, whether it applies and why, with evidence locations recorded.
Operate controls long enough to produce evidence
Before the certification audit, the controls in the Statement of Applicability must run in practice. Access reviews, change records, vulnerability scans, incident tests, supplier reviews and internal audits should exist as dated records, not plans. Self-hosted open-source tools can generate logs and configuration evidence inside the vendor's environment. Done means the owner of each control can show a recent record of it operating, and the internal audit and management review have been completed and recorded.
Pass the two-stage initial certification audit
The certification body runs a two-stage initial audit. Stage 1 reviews documentation and readiness for the audit, and stage 2 tests whether the management system is implemented and operating within the scope. The vendor is responsible for providing access to people and records, and the certification body alone decides the outcome. Nonconformities are answered with corrections and corrective actions within the timelines the certification body sets. Done means the certification body has issued a decision, and any certificate names the standard, its issue status and a scope that is not misleading or ambiguous.
Run the surveillance audit cycle
A management system certification cycle runs three years, and the certification body must carry out at least one audit in every calendar year, either surveillance or recertification. The vendor keeps controls operating between audits, tracks changes that affect the scope, and closes findings on schedule. Done means each annual audit has a report, corrective actions are verified, and the certificate remains valid for the scope the bank relies on. Confirm the audit programme and dates with the certification body.
Publish the certificate for bank verification
Once certified, the vendor gives banks the accredited certificate and the scope statement, and points them to the registry where it can be verified. The bank's third-party risk team can check it in IAF CertSearch, individually, in bulk or through the certification body or accreditation body. Done means the bank can confirm the certificate's status, standard, issue status and scope without relying on a copy the vendor sends.
Answer bank questionnaires and audit requests
Banks often add their own questionnaires, evidence requests and on-site or remote audit rights to the ISO report. The vendor should map each question to the Statement of Applicability and the evidence register, and provide the evidence the control owner already keeps. Where a bank asks for something beyond the certificate, such as a contingency test or a penetration test summary, the vendor should say what exists and what does not. Done means each request has a documented response, a named evidence owner and a record of what was shared.

Which assurance to offer a bank: certificate, SOC 2 or both

This table compares an ISO 27001 certificate, a SOC 2 report and a combined approach by what each one answers in a bank's due diligence. Read the rows against the exact request in the bank's questionnaire or contract, because the bank and the vendor make the final choice together.

Option	What it provides	When it fits the request
ISO 27001 certificate	A certificate from an accredited certification body stating that the information security management system meets the standard for a defined scope, valid for a three-year cycle with annual audits.	The bank asks for an internationally recognized certificate, works across several countries, or its third-party policy names ISO reports as acceptable independent assessments.
SOC 2 report (Type 1)	A CPA firm's description of the controls and an opinion on whether they were suitably designed at a single point in time, using the 2017 Trust Services Criteria.	The bank wants evidence of a US-style attestation quickly, or the vendor is early in its control program and needs a first independent report.
SOC 2 report (Type 2)	A CPA firm's opinion on whether controls operated effectively over a period, so it shows sustained operation rather than design alone.	The bank's due diligence asks how controls behaved over time, for example for access reviews, change management or incident handling.
Combined approach	An ISO 27001 certificate and a SOC 2 report built on the same control set, with the AICPA mapping used to show where criteria and Annex A controls overlap.	The bank accepts both forms, or different business units ask for different assurance, so the vendor avoids running two separate evidence programs.
Scope of the assurance	An ISO certificate covers the ISMS scope the vendor defines and the certification body accepts. A SOC 2 report covers the system description and the Trust Services Criteria the vendor selects.	The bank's critical service is inside the scope. Ask the vendor and the bank to confirm which systems, locations and services each report covers.
Who issues it	An accredited certification body issues the ISO certificate. A licensed CPA firm issues the SOC 2 report. DeployOpen prepares systems and evidence but does not issue either.	Confirm the certification body is accredited and check the certificate in IAF CertSearch, and confirm the CPA firm's licensing with the bank before accepting the report.
Recurring effort	ISO surveillance audits each year within the three-year cycle, and SOC 2 reports issued on a periodic basis that the bank tracks against its own review calendar.	Plan evidence collection once for both programs when the bank expects updates each year, so the same controls feed both audits.
Bank's own decision	The bank decides whether an accepted assurance satisfies its third-party risk policy, including whether it needs supplementary testing or on-site rights.	Ask the bank in writing which assurance it accepts, the scope it expects and whether it requires the vendor to share the full report.

Who owns each part of bank vendor assurance

The vendor owns the information security management system, the controls it runs, the contracts it signs and the answers it gives its bank customers. The scope decision sits here too: the vendor chooses which services, locations, systems and people fall inside the ISMS and writes that boundary into the Statement of Applicability. Because the bank contracts with the vendor, the vendor is also the party that must meet the bank's audit, inspection and incident notification terms.

Scope decision: Decide which bank-facing services, data flows and sites the ISMS covers, and record the reasons for exclusions.
Control ownership: Name an accountable owner for each Annex A control that applies, including access reviews, logging and supplier controls.
Contract terms: Negotiate audit rights, incident timelines, subcontractor flow-downs and exit assistance with each bank customer.
Management review: Run leadership reviews of risks and performance, and keep the minutes as evidence.
Bank questions: Answer due diligence questionnaires and explain any gap between the certificate scope and the service the bank buys.

Before relying on the certificate, confirm with the bank which service and sites it expects the scope to cover.

Why bank vendor reviews stall and how to avoid it

Bank due diligence rarely fails on the certificate itself. It stalls when the certificate covers the wrong scope, names the wrong legal entity, or leaves gaps against the contract terms a bank must enforce under DORA. The cards below cover the pitfalls that most often delay vendor reviews and what to check before the questionnaire arrives.

Scope excludes the bank-facing service

An ISMS scope is set by the organization, and a certificate only covers what is inside it. If the platform a bank uses sits outside the scope, or the scope names a product line that the bank never buys, the reviewer will ask for a new assessment. Check the scope statement against the service description in the bank contract, and confirm that the hosting environment, support desk and admin access paths are inside the boundary. The certification body's scope must not be misleading or ambiguous, so the wording should match how the service is actually sold.

Certificate names the wrong entity

Banks contract with a specific legal entity, but the certificate is issued to whichever organization the certification body audited. A parent company certificate, a certificate issued to a sister company, or a certificate for a site that does not deliver the service will not match the contract party. Confirm the legal name, the sites and the services listed on the certificate, and check the certificate in the IAF CertSearch database rather than relying on a PDF copy supplied by the vendor.

Certificate still on the 2013 edition

ISO/IEC 27001:2013 certificates had to expire or be withdrawn by 31 October 2025, the end of the transition period set by IAF MD 26:2023. A bank reviewer who finds a 2013 certificate, or a certificate with an unclear issue status, will treat the control set as out of date. Confirm that the current certificate names the 2022 edition, and ask the certification body for the transition audit report if the change was made late.

Missing evidence for DORA contract terms

For ICT services supporting critical or important functions, DORA Article 30 expects providers to accept precise service level targets, test business contingency plans, take part in the customer's threat-led penetration testing, and grant audit and access rights. A certificate does not evidence these terms by itself. Prepare documented service levels, recent continuity test records, a position on participating in TLPT, and a written audit access clause that the bank's lawyers can accept.

Unclear sub-outsourcing

Banks need to know which subcontractors and cloud providers touch their data or the service. When the vendor cannot list its subcontractors, their locations and the controls it checks on them, the review stalls. Map every material subcontractor to the service, confirm that its own certificates or audit reports are current, and state how the vendor will notify the bank of changes. Where the bank's policy requires it, keep the subcontractor list aligned with the Statement of Applicability and supplier controls.

Assurance that does not match the policy

A bank's third-party policy must specify which assurance it uses on each provider, such as its own audits, independent audit reports, the provider's internal audit reports or third-party certifications, and it may use more than one. A vendor that offers only an ISO certificate forces the bank to find other evidence. Ask the bank's risk team which assurance types it accepts for your service tier, then provide a current certificate alongside an audit report or internal audit summary where the policy calls for it.

Common questions from vendors selling to banks

Does a bank require ISO 27001 by name in its vendor contracts?

Not always. Requirements depend on the bank, the service and the contract, so there is no single rule to point to. Banks usually ask for evidence of an information security management system, and ISO 27001 is one of the most common ways to show it. A proposed Federal Reserve third-party risk guide for community banks lists ISO reports, alongside SOC 2 reports and other independent assessments, as examples a bank may review when assessing a cybersecurity vendor. Check the security schedule, the questionnaire and any due diligence request before you assume a specific standard is required, and ask the bank's procurement or third-party risk team which assurance they accept.

Is a SOC 2 report enough for a bank vendor review?

It can be, but it depends on what the bank asks for and what the service touches. SOC 2 and ISO 27001 are different products. SOC 2 is an attestation by a CPA firm against the AICPA Trust Services Criteria, and ISO 27001 is a certification issued by an accredited certification body against the ISO standard. Many banks accept either, and some ask for both. Under DORA, a financial entity's policy must name the assurance it relies on for each provider, such as independent audit reports or third-party certifications, and it may use more than one where appropriate. Map your existing SOC 2 controls against ISO Annex A before deciding which report to offer first.

What does DORA change for a vendor outside the EU?

DORA reaches non-EU vendors through the contracts that EU financial entities sign with them. The regulation requires EU financial entities to contract only with providers that comply with appropriate information security standards, and for services supporting critical or important functions, the contract must include precise service level targets, tested business contingency plans, participation in threat-led penetration testing, and unrestricted access, inspection and audit rights for the customer and the competent authority. Your location does not remove these terms. Ask the customer which DORA clauses they will put in the contract, and confirm with qualified legal counsel how the terms apply to your entity and the services you provide.

How much effort does ISO 27001 take from a vendor's own team?

Most of the effort falls on your staff, because the controls describe how your own people, systems and suppliers work. Effort rises with the size of the scope, the number of sites and cloud accounts, how many policies and procedures already exist, and how much evidence is collected by hand. Plan for an owner for the ISMS, named control owners across engineering, IT and HR, and time for risk assessment, internal audit and management review. Once certified, the cycle is three years with at least one audit in every calendar year, so the work recurs. Ask any consultant for a written breakdown of what they do and what your team must do.

Can an implementation partner also run the ISO 27001 audit?

No. An implementation partner can prepare systems, controls and evidence, but only an accredited certification body can audit your management system and issue a certificate. The certification body must be independent of the work it audits, so the firm that designed your controls should not also certify them. A sound approach is to ask the implementer to document what they delivered, then choose a certification body separately. Check that the certification body is accredited and ask which accreditation body accredited it, before you sign anything.

How do banks verify an ISO 27001 certificate is genuine?

Check the certificate against the registry of accredited certificates. ISO states that a certificate issued by an accredited certification body can be verified in IAF CertSearch, either one at a time, in bulk or through an API, or by contacting the certification body or accreditation body directly. Confirm that the certificate names ISO/IEC 27001 with its issue status, that its scope matches the services the bank buys, and that it lists your sites, locations and any exclusions. A certificate whose scope is vague or refers to standards outside the accredited scope should be questioned. Keep a copy of the registry result in the bank's due diligence file.

What should a bank ask for beyond the certificate itself?

A certificate shows that an audit took place against a defined scope, but banks often want more detail. Typical requests include the Statement of Applicability, the most recent internal audit and management review records, the list of significant suppliers and their assurance reports, penetration test summaries, incident response and business continuity test results, and evidence of access control and logging for the systems that handle their data. Ask the bank which of these it needs, in what format, and under what confidentiality terms, so you prepare the right evidence once rather than answering the same questionnaire repeatedly.

How DeployOpen prepares ISO 27001 evidence for bank vendor reviews

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For vendors selling to banks, we prepare the systems, controls and evidence that a bank reviewer and an independent certification body will look at, while the organization keeps ownership of its controls and the certification decision stays with the certification body.

How we scope

Agree the ISMS scope in writing, covering the services and systems the bank will actually rely on
Map the bank's due diligence questions to the Annex A controls the vendor must evidence
Confirm which parts of the environment are in scope, and which suppliers and cloud services sit inside the boundary

How we build

Implement and harden the open-source platforms that run access, logging, backup and change controls
Configure evidence collection so records such as access reviews and vulnerability scans are produced routinely
Test controls against their stated purpose before the organization asks an auditor to look at them

How we hand over

Deliver system documentation, control descriptions and an evidence index that the organization owns
Prepare a Statement of Applicability draft and supporting records for the organization's review and approval
Walk the organization's staff through how each control is operated and where its evidence is kept

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends
Keep evidence current for surveillance audits and for bank questionnaires as systems change
Confirm with your certification body which evidence it expects before the audit, since it alone issues the certificate

ISO 27001 for vendors selling to banks and financial institutions