ISO 27001 for Fintech in the Philippines: What the BSP, the NPC and Your Bank Partners Actually Test

Who supervises which kind of fintech, what an ISO/IEC 27001:2022 certificate proves and what it does not, how to scope a cloud-native platform, which Annex A controls carry the weight, and what a bank’s third-party risk team will ask you for.

Short answer

No Philippine regulator requires ISO/IEC 27001 certification. That is precisely why it is worth having. The Bangko Sentral ng Pilipinas expects supervised institutions to demonstrate sound information-security and technology-risk management; it does not prescribe a certificate. The National Privacy Commission enforces the Data Privacy Act of 2012 over your personal data; it does not prescribe a certificate either. What both, plus every bank partner and every institutional investor, actually ask for is evidence that your controls are governed, tested and improved. An accredited ISO/IEC 27001:2022 certificate is the most portable single artefact that answers that question.

The trap is the inverse claim. A consultant who tells you ISO 27001 makes you “BSP compliant” is selling you paper. The obligations under the Manual of Regulations, the Data Privacy Act and the Anti-Money Laundering Act remain yours whether or not you hold a certificate. What the ISMS gives you is the machinery to meet them repeatably — and the records to prove you did.

Is it mandatory?

No

Not required by the BSP, NPC, SEC or AMLC. Required constantly by bank partners and investors.

Standard

27001:2022

Plus Amendment 1:2024 on climate change. 93 Annex A controls.

Typical fintech timeline

7–12 months

Sterling project experience for a cloud-native platform of 20–150 people.

Companion standards

27017 · 27701 · 22301

Cloud, privacy and continuity. PCI DSS if you touch card data.

This is the financial-services spoke of our full guide to ISO 27001 certification in the Philippines. For incumbent banks and insurers running a multi-standard programme across ISO 27001, ISO 22301 and ISO 9001, see ISO certification for banking and financial services instead.

Who this page is for, and who actually supervises you

“Fintech” in the Philippines covers at least six materially different regulatory positions, and the first thing that goes wrong in an ISMS project is that the founders have not worked out which one they are in. Your supervisor determines what evidence you will be asked for, who can ask for it, and how much notice you get.

Kind of business Primary supervision What that means for your ISMS
Digital bank or thrift/rural bank with a digital channel Bangko Sentral ng Pilipinas, as a bank. The full weight of banking supervision: technology risk, information security, outsourcing, business continuity and consumer protection. Examiners can and do ask to see control evidence directly.
Electronic money issuer (EMI) BSP, under the e-money framework in the Manual of Regulations. Float safeguarding and settlement integrity sit alongside information security. Availability is a supervisory issue, not just a commercial one.
Operator of a payment system (OPS) BSP, under Republic Act No. 11127, the National Payment Systems Act of 2018. Registration with the BSP, and operational and security expectations proportionate to how systemically important the system is judged to be.
Remittance and transfer company, or virtual asset service provider BSP, plus AMLA obligations as a covered person. Customer due diligence records, transaction monitoring and record retention become information assets with statutory retention periods attached.
Lending or financing company, including online lending platforms Securities and Exchange Commission — for lending companies, under Republic Act No. 9474. The SEC has been markedly more aggressive on borrower data handling and collection practices than on network security. Your privacy controls carry the exposure.
Software vendor or processor selling into the above Not directly supervised — supervised through your clients’ outsourcing obligations. You inherit your clients’ requirements by contract, without their timelines or their leverage. This is the group for which certification pays back fastest.
If you are in the last row, read that row twice. A supervised institution cannot outsource away its accountability, so it pushes the control requirements down to you contractually — and then audits you. Every enterprise sale becomes a security assessment. Certification converts a recurring six-week assessment into a document you attach to the proposal.

Why ISO 27001, when no Philippine regulator requires it

Let us be exact about this, because the sales pitch you will hear elsewhere is not exact. There is no Philippine law, circular or memorandum that requires a fintech company to hold an ISO/IEC 27001 certificate. Anyone who tells you otherwise has either misread a regulation or is hoping you will not check.

What is true is narrower and more useful. Philippine financial regulation is written in outcome language — sound risk management, adequate controls, appropriate oversight by the board. Outcome language creates an evidence problem: you have to demonstrate adequacy to someone who has not seen your systems. There are only a few ways to do that credibly, and an accredited management system certificate is the cheapest of them per audience reached.

The question you get asked Who asks it What an ISO 27001 certificate does about it
“Demonstrate that information security is governed at board level.” Examiners; institutional investors during diligence. Clauses 5.1, 5.2, 5.3 and 9.3 are exactly this, and the audit trail is already assembled. Substantially answered.
“Show us your risk assessment methodology and its results.” Bank partners; enterprise clients; examiners. Clause 6.1.2 requires a repeatable, comparable method; 6.1.3 requires the treatment plan and Statement of Applicability. Fully answered.
“How do you assure the security of your third parties?” Every supervised counterparty you sell to. A.5.19 to A.5.22 cover supplier relationships and service delivery management end to end. Fully answered.
“Are your customer due diligence records complete and retained?” AMLC; internal audit; examiners. The ISMS protects and controls access to those records. It does not create them or verify their AML adequacy. Partly answered — and no further.
“Is your capital adequate and are your disclosures correct?” BSP; SEC. Nothing. Out of scope entirely, and any consultant implying otherwise is inventing.

The honest summary: certification does most of the work on the governance and control-evidence questions, some of the work on records management, and none of the work on prudential or conduct obligations. That is still a very good trade, because the governance and control questions are the ones that repeat with every counterparty.

There is a second, less discussed return. Fintech companies in the Philippines raise capital from investors who are not in the Philippines. Those investors do not know the Manual of Regulations, and they are not going to learn it during diligence. They know ISO 27001 and they know SOC 2. A certificate translates your control environment into a vocabulary the person writing the cheque already reads.

The regulatory map: BSP, the NPC, the AMLC and the SEC

Four bodies can reach into your control environment, and they want different things. Confusing them is how programmes end up over-built in one direction and exposed in another.

Body Instrument What it is actually about ISMS touchpoint
Bangko Sentral ng Pilipinas The Manual of Regulations for Banks and for Non-Bank Financial Institutions, as amended by circular. Technology risk management, information security management, outsourcing, business continuity, and consumer protection under Republic Act No. 11765. Nearly all of it. Clauses 5, 6, 8 and 9 plus the supplier and continuity controls.
National Privacy Commission Republic Act No. 10173, the Data Privacy Act of 2012, and its implementing rules. Lawful processing, data subject rights, a designated Data Protection Officer, registration of data processing systems where required, and personal data breach notification. Overlaps heavily but is not the same system. See the privacy section below.
Anti-Money Laundering Council Republic Act No. 9160, the Anti-Money Laundering Act of 2001, as amended. Covered person obligations: customer due diligence, covered and suspicious transaction reporting, and record retention. Indirect. The ISMS protects the records and controls access; it does not discharge the obligation.
Securities and Exchange Commission Republic Act No. 9474 for lending companies, and the corporation and securities framework generally. Registration, disclosure, and — in practice for online lenders — borrower data handling and collection conduct. Privacy controls and A.5.34, plus access control over borrower data.
How to cite BSP requirements without being wrong. The BSP issues circulars, but circulars are consolidated into the Manual of Regulations, and the operative text is the manual provision as it currently stands — not the circular as originally published. Circular No. 808 (2013) introduced the guidelines on information technology risk management, and Circular No. 982 (2017) issued enhanced guidelines on information security management. Both matter historically and both have been carried into the manual and amended since. If a proposal, policy or audit report you are handed cites a circular number as though it were a standing document, that is a signal the author has not checked the current manual provision. Check it before you rely on it, and before you write it into your own policy.

This matters for a practical reason beyond pedantry. Your ISMS documented information will reference legal and regulatory requirements — clause 4.2 requires you to determine them, and A.5.31 requires you to identify and document legal, statutory, regulatory and contractual requirements. If your register of those requirements cites superseded circular numbers, an auditor who knows the sector will treat the whole register as unmaintained. We have seen that single finding unravel an otherwise clean Stage 2.

What ISO 27001 does not do — stated plainly

Every consultant in this market publishes a page telling you what ISO 27001 gives you. Here is the other half, because you will be more effective knowing it, and because the gaps are where fintech companies actually get hurt.

Obligation Does an ISO 27001 certificate address it?
Prudential requirements — capital, liquidity, float safeguarding No. Entirely outside the scope of an information security management system.
AML programme adequacy — whether your customer due diligence and monitoring are sufficient No. The ISMS secures the records and the monitoring platform. Whether the programme detects the right things is an AML question assessed against AMLA, not against Annex A.
Consumer protection conduct under Republic Act No. 11765 Barely. Complaint records and their integrity, yes. Whether your disclosure and redress practices are fair, no.
Lawfulness of processing under the Data Privacy Act No. ISO 27001 is about protecting information, not about whether you had a lawful basis to collect it. That is a privacy management question — ISO/IEC 27701 territory.
Cardholder data controls to the card schemes’ satisfaction No. PCI DSS is prescriptive and separately assessed. There is useful overlap in evidence, none in the assessment itself.
Software correctness — that your ledger reconciles and your interest calculation is right No. A.8.25 to A.8.29 govern how you build software securely. They do not certify that what you built is correct.
That you will not be breached No, and be suspicious of anyone who implies otherwise. It certifies that you manage the risk deliberately and improve when something goes wrong.

Read that table as a scoping instrument rather than a discouragement. Everything in the left column still has to be done. Knowing that the ISMS will not do it stops you from discovering the gap during a regulatory examination, which is the worst possible time to discover it.

Scoping a fintech ISMS under clause 4.3

Clause 4.3 requires you to determine the boundaries and applicability of the ISMS, considering the external and internal issues from 4.1, the requirements of interested parties from 4.2, and the interfaces and dependencies between what you do and what others do for you. The scope must be available as documented information — it is one of the fifteen mandatory documents.

The characteristic fintech scoping error is to draw the boundary around engineering. It feels right: engineering owns the platform, the platform is the product, so certify engineering. It fails at the first serious customer review, because the questions that follow a certificate are about the whole path a transaction takes.

Scope element Commonly left out Why leaving it out fails
Production platform and data stores Never. This is the part everyone includes.
Customer support and operations tooling Frequently. Support agents can typically see or amend customer records, reverse transactions, or trigger resets. In this sector most realised internal fraud runs through operations tooling, not through the codebase.
Non-production environments holding real data Almost always, and usually without anyone realising real data is there. A staging database restored from a production snapshot is a production data store with weaker controls. Excluding it is not a scoping decision, it is an unmanaged risk.
Corporate IT: laptops, identity, email, collaboration Sometimes, on the theory that it is not the product. Every credential that reaches production originates on a corporate device. An auditor will follow that path and so will an attacker.
Third-party processors and BPO providers Often reduced to a line in a supplier register. Clause 4.3 requires interfaces and dependencies to be considered. A.5.19 to A.5.22 then require the relationship to be managed, monitored and reviewed — not merely recorded.
Cloud infrastructure and managed services Not excluded, but usually not analysed by responsibility split. You cannot state what you control without stating what the provider controls. That analysis is the whole point of ISO/IEC 27017.
A scope statement worth issuing names the services, the locations including cloud regions, the organisational units, and the exclusions with a reason for each. “The information security management system supporting the design, development and operation of the Company’s payment platform” is a marketing sentence, not a scope. If a bank’s vendor manager cannot tell from your certificate whether your support desk is inside the boundary, the certificate will not close the assessment — which was the reason you bought it.

Scope decisions drive the Statement of Applicability, which is where they become visible to an auditor. Our page on risk assessment and the Statement of Applicability covers clause 6.1.3 in full, including why Annex A is a completeness cross-check applied after you determine controls, not a menu you shop from.

The Annex A controls that carry the weight in fintech

All 93 controls in ISO/IEC 27001:2022 Annex A are candidates, and clause 6.1.3 d) requires you to justify any you exclude. But in this sector a predictable subset is where audits concentrate, where findings land, and where bank due diligence questionnaires aim. If your implementation budget is finite — it is — these are the controls to over-invest in.

Control Title Why it is disproportionate in fintech
A.5.7 Threat intelligence New in 2022. Payment and lending platforms are targeted by campaigns with known signatures. An auditor will ask what feeds you consume and what you did with the last item that mattered.
A.5.19–A.5.22 Supplier relationships, security in agreements, ICT supply chain, monitoring and change management of supplier services The single densest cluster of findings in this sector. A fintech stack is mostly other people’s software: KYC vendors, card processors, cloud, SMS gateways, credit bureaus.
A.5.23 Information security for use of cloud services New in 2022. Covers acquisition, use, management and exit. Most organisations can evidence the first three and nothing on exit.
A.5.30 ICT readiness for business continuity New in 2022. For an EMI or OPS, availability is a supervisory concern. Recovery objectives must be derived from a business impact analysis and then actually tested.
A.5.34 Privacy and protection of personally identifiable information The direct hook to the Data Privacy Act. Auditors familiar with the Philippine market will test this one specifically.
A.8.9 Configuration management New in 2022. Infrastructure defined in code is a gift here — but only if drift between the code and the running environment is detected and corrected.
A.8.11 Data masking New in 2022. The control that closes the non-production data problem, and the reason to fix it properly rather than by excluding staging from scope.
A.8.12 Data leakage prevention New in 2022. In practice, the control that governs bulk export from operations tooling — the highest-value internal threat path in the sector.
A.8.15–A.8.16 Logging; monitoring activities A.8.16 is new in 2022. Financial platforms generate enormous log volume; the audit question is not whether you log but whether anything reads the logs and what happened the last time something did.
A.8.24 Use of cryptography Key management is where this fails. Card data, credentials and personal data all depend on it, and a policy without a key lifecycle is not a control.
A.8.25–A.8.28 Secure development lifecycle, secure coding, security testing in development and acceptance, and outsourced development A.8.28 is new in 2022. If you ship weekly, these four are what make that defensible rather than alarming.
A.8.31–A.8.32 Separation of development, test and production environments; change management Where a fast-moving engineering culture and a management system meet. See the next-but-one section.

Two observations that follow from that list. First, seven of the eleven controls added in the 2022 edition appear on it — the revision was written with cloud-native, continuously deployed platforms in view, which is to say with you in view. Second, the 2022 edition consolidated 57 of the 2013 controls into 24, split one into two, carried 56 forward individually and added 11 new: 24 + 2 + 56 + 11 = 93, drawn from 57 + 1 + 56 = 114. Nothing was removed. If you are migrating a control set built against the 2013 edition, every one of your existing controls has somewhere to go.

The complete list, with all four themes and every control title, is on our ISO 27001 Annex A controls page.

Cloud concentration, ISO/IEC 27017 and the exit you cannot execute

Practically every Philippine fintech platform built in the last decade runs on one hyperscaler, in one or two regions, with managed databases and managed queues. That is a sensible engineering decision and a concentration risk, and supervised counterparties have started asking about it in those terms.

The regulator’s question is not “is it in the cloud.” The BSP’s outsourcing expectations, and the equivalent expectations your bank clients pass down to you, come to three things: can you identify who is accountable for each control, can you obtain assurance that the provider performs, and can you continue operating — or exit — if the arrangement fails.

The question What an auditor wants to see What is usually there instead
Who controls what? A documented shared-responsibility analysis, per service, mapping each relevant Annex A control to you, the provider, or both. The provider’s generic marketing diagram, printed and filed.
How do you assure their performance? Their current certifications and assurance reports, read, with the complementary user entity controls extracted and assigned to named owners. A downloaded PDF nobody has opened past the cover page.
What about the sub-processors? A register that goes at least two tiers deep for anything touching customer data, with notification rights in the contract. A first-tier supplier list. Their suppliers are invisible.
Can you exit? A tested plan: where the data goes, in what format, how long it takes, what breaks, who decides. A.5.23 explicitly covers exit from cloud services. A contract clause saying data will be returned on request, with no plan behind it.
Where is the data, physically? Region and availability-zone facts per data store, and the cross-border position assessed against the Data Privacy Act. “Singapore, we think.”

ISO/IEC 27017:2015 is the sector-specific guidance for cloud services, giving cloud-specific implementation guidance for ISO/IEC 27002 controls plus additional controls for cloud customers and providers. It is guidance, not a separately certifiable management system standard — it is assessed as an extension of an ISO/IEC 27001 certification, which is a distinction worth knowing before someone quotes you for a standalone certificate. A second edition has completed development and is at publication stage; until it is on the catalogue and accredited bodies have transitioned, 27017:2015 is what a certificate can cite.

The exit plan is the control most likely to be missing and the one that takes longest to build, because writing it forces you to discover which managed services you have used in ways that cannot be replicated elsewhere. Start it in month two, not in the week before Stage 2. In our experience it is also the single artefact that most impresses a bank’s third-party risk team, because almost no vendor has one.

Continuous deployment inside a management system

The objection we hear in every fintech kickoff: “we deploy eleven times a day, we are not going to raise a change request for each one.” Correct, and nothing in ISO/IEC 27001 asks you to. A.8.32 requires changes to information processing facilities and information systems to be subject to change management procedures. It does not prescribe a ticket, a board, or a window.

What it requires is that changes are controlled, and that you can demonstrate the control operated. A well-run deployment pipeline produces better evidence than a change advisory board ever did — it is machine-generated, complete, and impossible to backdate. The work is in making the pipeline’s existing behaviour legible as a control.

Requirement The heavyweight interpretation What actually satisfies it
Changes are authorised A change advisory board meets weekly. A merge requires an approving review from someone other than the author, enforced by branch protection, and the approval is in the commit record permanently.
Changes are tested before release A signed test report per release. The pipeline runs the test suite and the security scans, and refuses to promote on failure. The run log is the record. A.8.29 covers security testing in development and acceptance.
Segregation of duties (A.5.3) Developers may never touch production. A.5.3 requires conflicting duties and areas of responsibility to be segregated. In a 15-person team, achieve it through the pipeline: humans cannot deploy directly, the pipeline deploys, and standing production access is nobody’s.
Emergency changes A separate emergency process that nobody follows at 02:00. The same pipeline with an expedited approval path, plus a mandatory review of every emergency change at the next operational meeting. Auditors sample emergency changes first — assume it.
Production data access A blanket prohibition that gets bypassed within a month. Time-bound, approved, logged and reviewed elevation. Break-glass with an alert to someone who is not the requester. This is where A.8.2, A.8.11 and A.8.18 meet.
Environment separation (A.8.31) Separate physical infrastructure. Separate accounts or projects, separate credentials, no network path from lower environments to production data, and masked or synthetic data below production.

The failure mode to avoid is a consultant who writes you a change management procedure describing a process you do not operate. You will then fail the internal audit against your own document, which is clause 9.2.1’s first test. Document what the pipeline does. If the pipeline does not enforce something the risk assessment says it should, change the pipeline — not the document.

The Data Privacy Act, the NPC and where ISO 27701 starts

Republic Act No. 10173, the Data Privacy Act of 2012, applies to you regardless of who supervises your financial activity, and fintech processes personal data at a density few sectors match: identity documents, selfies and liveness data, device fingerprints, contact graphs, transaction histories, and for lenders, income and employment data.

The Act and its implementing rules produce obligations that an ISMS partially covers and partially does not:

Obligation under the Data Privacy Act framework ISO/IEC 27001 coverage Where the rest comes from
Designating a Data Protection Officer None — ISO 27001 requires roles and responsibilities (5.3) but not this role. The Act and NPC issuances directly. In practice the DPO and the ISMS manager coordinate constantly and should not be the same overloaded person in a growing company.
Lawful basis and proportionality of processing None. ISO 27001 protects data; it is indifferent to whether you should hold it. ISO/IEC 27701, which extends the ISMS into a privacy information management system.
Registration of data processing systems where required None. NPC registration requirements directly. Your ISMS asset inventory makes assembling the submission far easier.
Security measures for personal data Substantial — organisational, physical and technical measures are what Annex A is. Largely covered. A.5.34 is the explicit hook.
Personal data breach notification Partial. A.5.24 to A.5.28 give you incident management, assessment, response and evidence collection. The notification decision, timing and content are set by the Act and NPC issuances. Build the regulatory clock into the incident procedure — the deadline runs from knowledge or reasonable belief, not from the end of your investigation.
Data subject rights requests None as a process. Access control and records management support it. ISO/IEC 27701 covers this properly, including the processor obligations if you handle data on behalf of a bank client.
If a material part of your business is processing personal data on behalf of others — a KYC vendor, a card processor, a BPO running collections — then ISO/IEC 27701:2025 is worth serious consideration. The 2025 edition is a standalone certifiable management system standard rather than an extension you can only certify alongside 27001, which changes the commercial calculation. It is also the fastest way to answer a controller’s processor-assurance questions without a bespoke audit each time.

When PCI DSS is also in play

If you store, process or transmit cardholder data, PCI DSS applies to you. Note where the obligation comes from: it is imposed contractually by the card schemes and passed down through your acquirer or sponsor bank. It is not a BSP requirement, and a consultant who presents it as one has not read either.

ISO/IEC 27001:2022 PCI DSS v4.0.1
What it is A management system standard. Risk-based; you determine the controls. A prescriptive control standard. The requirements are fixed and apply to the cardholder data environment.
Who imposes it Nobody. You choose it. The card schemes, contractually, through your acquirer.
Scope logic You define the scope; the certificate states it. Scope is determined by where cardholder data flows. You reduce it by not touching the data.
Assessment An accredited certification body. Three-year cycle with annual surveillance. A Qualified Security Assessor or a self-assessment questionnaire, depending on level. Annual, with quarterly scanning obligations.
Outcome A certificate. An Attestation of Compliance, valid to the date of assessment.
Failure consequence No certificate. Commercial. Scheme fines and, in the extreme, loss of the ability to accept cards. Existential.

Version position, because this is where dated pages mislead: PCI DSS v3.2.1 was retired on 31 March 2024. The current version is v4.0.1, published in June 2024 as a limited revision of v4.0. The requirements that v4.0 designated as future-dated became mandatory on 31 March 2025, so “we are working towards those” is no longer an available position.

The strategic advice for a fintech: reduce scope before you build controls. Tokenisation, a hosted payment page, or routing card data straight to a compliant processor without it landing in your systems will cut the assessed environment more than any control investment. Then run ISO 27001 across the whole organisation and PCI DSS across what is left. Our PCI DSS certification page covers the levels, the assessment routes and the scoping mechanics.

ISO 27001 or SOC 2 if you sell outside the Philippines

Philippine fintech companies selling to United States buyers hit this fork early, usually because a prospect asked for SOC 2 by name. The answer is determined by who is asking, not by which is better.

If your buyers are… Ask for Reasoning
United States enterprises and US-based venture investors SOC 2 Type 2 first. It is the vocabulary they use. An ISO 27001 certificate will be accepted but often triggers a supplementary questionnaire that a SOC 2 report answers directly.
Philippine and regional banks, and enterprises in the Gulf, Europe, Japan or Australia ISO 27001 first. Accredited certification is the recognised proof outside the United States, and it is what BSP-supervised counterparties reference.
Both, which is the usual answer ISO 27001 as the system, SOC 2 as the report. Build one control environment, then evidence it twice. The incremental cost of the second is far below the cost of the first, because the controls, evidence and ownership already exist.

The framing that saves money: ISO 27001 certifies a management system, SOC 2 reports on the operating effectiveness of controls over a period against the Trust Services Criteria. They are different artefacts produced from the same underlying control environment. Sequencing them as two separate projects, with two sets of documentation, is the expensive way to do it and unfortunately the way it is usually sold. Our SOC 2 compliance guide for the Philippines covers Type 1 versus Type 2, the criteria and the costs.

The diligence pack a bank actually asks you for

If you sell into supervised institutions, you will complete third party risk assessments repeatedly. Here is what those requests contain in this market, and which ISMS artefact answers each. Assembled in advance, this pack turns a six-week assessment into a two-day one — and that time saving, not the certificate itself, is usually where the return on the project shows up first.

What they ask for What you send
Proof of certification The certificate, plus the accreditation body’s or certification body’s public register entry so they can verify it independently. Send the link unprompted; it pre-empts the follow-up.
Scope confirmation The scope statement from the certificate, and if your scope excludes something relevant to them, say so before they find it.
Statement of Applicability The SoA, or an extract. Under clause 6.1.3 d) it states necessary controls, justification for inclusion, implementation status, and justification for any Annex A exclusion. Exclusions will be questioned — have the reasoning ready.
Information security policy The clause 5.2 policy. One document, signed by top management, current.
Risk assessment methodology The clause 6.1.2 methodology — not the risk register itself. Almost nobody should be sending their full register to a prospect.
Latest internal audit and management review Summary outputs, not raw reports. Under clauses 9.2 and 9.3 these exist; you control the level of detail disclosed.
Penetration test results The most recent test summary and the remediation status of findings. Redacted technical detail is normal and expected.
Business continuity and disaster recovery evidence The plan, the last test date and the test result. A.5.29, A.5.30 and, if you have gone further, an ISO 22301 certificate.
Incident history and notification commitments Your incident management procedure and the notification timelines you commit to contractually. Have this aligned with the Data Privacy Act clock before you sign anything.
Subcontractor list The supplier register, at least for anything touching their data. A.5.19 to A.5.22.
One practical instruction that consistently pays: assemble this pack once, keep it current, and give a named person ownership of it. The commonest cause of a stalled enterprise deal in this sector is not a failed control — it is a security questionnaire sitting with a founder for three weeks because nobody else can answer it.

What makes a fintech project cost more than a services firm

Our published planning corridor for ISO 27001 in the Philippines runs from roughly ₱560,000 to ₱1,430,000 all in, combining consulting of ₱255,000 to ₱630,000 with certification body audit fees of ₱300,000 to ₱800,000, before the 12 per cent VAT. A fintech platform typically sits in the upper half of that corridor, and it is worth understanding exactly why so you can judge a quotation.

Cost driver Effect What you can do about it
Multiple environments and infrastructure as code More systems in scope, but each is more uniform. Net roughly neutral if your infrastructure really is defined in code. Expensive if half of it is and half is not, because the exceptions carry all the evidence burden.
Third-party density The largest single driver. A supplier assessment is real work and a fintech stack has many. Tier your suppliers by data access and criticality, and assess proportionately. Assessing forty suppliers identically is a consultant billing pattern, not a risk-based approach.
24×7 availability expectations Continuity and ICT readiness work under A.5.29 and A.5.30 goes well beyond a documented plan. Budget for a real recovery test. It is the deliverable that gets cut and the one that most often causes a finding.
Regulated counterparties in scope Contractual security requirements flow down and must be reconciled with the ISMS under clause 4.2 and A.5.31. Collect every client security addendum before you start. Discovering a conflicting obligation in month seven is the expensive path.
Small team, hard segregation Segregation of duties and internal audit impartiality are harder below about 25 people. Automate segregation through the pipeline; contract internal audit externally. Both are cheaper than hiring for independence.
Personal data volume Data mapping, retention and deletion become substantial work items rather than paperwork. Do it once, properly, and reuse it for Data Privacy Act registration and any ISO 27701 work later.

Sterling project experience across Philippine implementations puts a cloud-native fintech of 20 to 150 people at seven to twelve months from kickoff to certification decision. The floor is not set by documentation; it is set by clauses 9.1, 9.2 and 9.3, which require the ISMS to have produced real monitoring results, a real internal audit and a real management review before Stage 2. That sequence is set out in full on our certification process and timeline page, and the full cost breakdown is on the ISO 27001 cost page.

ISO/IEC 27001 sets no minimum operating period before Stage 2. Certification bodies set expectations, and those expectations are policy rather than a requirement of the standard. Anyone quoting you “three months minimum, it is in the standard” is repeating something they have not checked. What the standard actually requires is records that exist because the processes ran — which usually takes about that long anyway, but for a reason you can plan around.

Seven mistakes we see in Philippine fintech ISMS projects

# The mistake What it costs
1 Scoping to the engineering team. The certificate does not close customer assessments, because the questions are about support, operations and third parties. You paid for a certificate that does not do the job you bought it for. Rescoping means re-auditing.
2 Buying a document toolkit and calling it an ISMS. A toolkit gives you documents. Clause 9.2.1 tests whether you do what your documents say, so a toolkit describing a process you do not operate manufactures nonconformities against yourself. This is the most expensive shortcut in the market.
3 Treating the risk assessment as a form to complete. Clause 6.1.2 requires a method producing consistent, valid and comparable results. A one-off spreadsheet nobody revisits fails at the first surveillance audit, when the assessor asks what changed after you launched a product.
4 Ignoring non-production data. The highest-likelihood personal data breach path in this sector. It is also a Data Privacy Act exposure, not merely an ISMS finding, and A.8.11 exists precisely to close it.
5 Citing superseded circular numbers in the legal register. A.5.31 requires legal, statutory, regulatory and contractual requirements to be identified, documented and kept up to date. A register full of stale citations tells a sector-literate auditor that nothing in it has been reviewed.
6 Letting the certification body do your gap assessment. Under ISO/IEC 17021-1 a certification body may not provide management system consultancy to an organisation it certifies. Blur that line and you can lose the certificate. Our page on certification bodies sets out the boundary.
7 Certifying to close one deal, then stopping. Surveillance arrives within twelve months of the certification decision. An ISMS that stopped operating the day after Stage 2 produces a bad surveillance audit and, in the worst case, suspension — which is materially worse commercially than never having certified.

Sterling Academy · e-learning for your people

Training that stands up in your ISO 27001 audit

Sterling consulting clients benefit from preferential course access and special pricing on Sterling Academy through their Sterling consultant, including complimentary ISO 27001 awareness training for your people as part of your engagement. Your consultant sets up your client administrator, you add your people, and every learner who completes a course and its final exam receives a numbered Certificate of Completion, verifiable online.

Completion records and certificates are your evidence for ISO/IEC 27001:2022 clauses 7.2 (competence) and 7.3 (awareness) and for Annex A control 6.3, information security awareness, education and training — the items a certification auditor tests by interviewing your staff.

Courses for an information security management system

End to end with Sterling: your ISO 27001 engagement includes

  • Implementation consulting through Design™ (guided) or Drive™ (fully managed), up to the certification audit
  • Sterling Academy e-learning for your people: preferential course access and special pricing, with complimentary ISO 27001 awareness training
  • Live internal auditor training for your audit team
  • Effivity ISMS software subscription
  • Vulnerability assessment by Cyber Vantage 360
  • Sustain™ post-certification support: internal audits, management reviews and surveillance preparation

List price from US$19 per learner per course (51–200 learners) · 12 months’ access · final exam included

Contact usSee the course on Sterling AcademyWatch the sample video →

Certificate of Completion issued after the final exam, numbered and verifiable online · Sterling consultant, client administrator and learner roles as on Sterling Academy

ISO 27001 for fintech: frequently asked questions

1. Does the BSP require ISO 27001 certification?
No. The Bangko Sentral ng Pilipinas does not require ISO/IEC 27001 certification of any supervised institution. What it requires is sound information security and technology risk management, demonstrated to its satisfaction. Certification is one credible way to demonstrate that, and it is the most portable, because the same certificate also answers bank partners, enterprise clients and investors. Any consultant telling you the BSP mandates ISO 27001 is misrepresenting the regulation.

2. Will ISO 27001 make us compliant with the Data Privacy Act?
No, and this is the most commonly oversold claim in the Philippine market. ISO/IEC 27001 will substantially cover the security measures the Act requires, and control A.5.34 addresses protection of personally identifiable information directly. It does not address lawful basis, proportionality, data subject rights processes, the designation of a Data Protection Officer, or registration of data processing systems. For those, you need a privacy programme, and ISO/IEC 27701:2025 is the management system standard built for it.

3. We are a software vendor, not a regulated entity. Do we need this?
You are the group for which certification usually pays back fastest. Supervised institutions cannot outsource their accountability, so they push control requirements down to you contractually and then assess you. Without a certificate, every enterprise sale carries a bespoke security assessment lasting weeks. With one, most of that assessment is answered by documents you already hold.

4. How long does ISO 27001 take for a fintech company?
Sterling project experience across Philippine implementations puts a cloud-native platform of 20 to 150 people at seven to twelve months from kickoff to certification decision. The constraint is not writing documents. Clauses 9.1, 9.2 and 9.3 require monitoring results, an internal audit and a management review to have genuinely happened before Stage 2, and those need the ISMS to have been running for a meaningful period first.

5. Can we get certified if everything runs on AWS or Azure?
Yes, and most Philippine fintech platforms do. What you need is a documented shared-responsibility analysis showing which controls are yours and which are the provider’s, evidence that you have read and acted on the provider’s assurance reports including their complementary user entity controls, and an exit plan. Control A.5.23 covers cloud services from acquisition through to exit, and the exit element is the one most organisations cannot evidence.

6. Do we need PCI DSS as well as ISO 27001?
Only if you store, process or transmit cardholder data. PCI DSS is imposed contractually by the card schemes through your acquirer, not by the BSP. If it does apply, reduce scope first through tokenisation or a hosted payment page, then run ISO 27001 across the organisation and PCI DSS v4.0.1 across the remaining cardholder data environment. Version 3.2.1 was retired on 31 March 2024, and the v4.x requirements that were future-dated became mandatory on 31 March 2025.

7. Should we do SOC 2 instead?
It depends entirely on who is asking. United States enterprise buyers and US venture investors ask for SOC 2 by name. Philippine and regional banks, and buyers in Europe, the Gulf, Japan and Australia, recognise accredited ISO 27001 certification. If you sell into both, build one control environment and evidence it twice — ISO 27001 as the management system and SOC 2 as the report. The second costs far less than the first because the controls and evidence already exist.

8. How do we deploy continuously and still satisfy change management?
Control A.8.32 requires changes to be subject to change management procedures. It does not require a change advisory board, a ticket per release, or a deployment window. A pipeline that enforces peer review before merge, runs security testing before promotion, refuses to promote on failure and logs every run produces stronger evidence than a manual process, because it is machine-generated and cannot be backdated. Document what the pipeline actually does, then make the pipeline do anything the risk assessment says is missing.

9. Our team is fifteen people. Can we achieve segregation of duties?
Yes, through automation rather than headcount. Control A.5.3 requires conflicting duties and areas of responsibility to be segregated. In a small team you achieve that by removing standing production access from everyone, having the pipeline perform deployments, requiring an approving review from someone other than the change author, and using time-bound approved elevation for production data access. For internal audit, clause 9.2.2 b) requires objectivity and impartiality of the audit process, which small teams normally meet by contracting the audit externally.

10. What does ISO 27001 certification cost for a Philippine fintech?
The published planning corridor is roughly ₱560,000 to ₱1,430,000 in total before 12 per cent VAT, combining consulting of ₱255,000 to ₱630,000 with certification body audit fees of ₱300,000 to ₱800,000. Fintech projects usually sit in the upper half, driven mainly by third-party density, availability and continuity requirements, and the volume of personal data to be mapped and governed.

Talk to consultants who have implemented in this sector

Sterling implements ISO/IEC 27001 for BSP-supervised institutions, payment operators, lenders and the vendors that serve them. We scope to the transaction path rather than the org chart, build the supplier and cloud evidence a bank’s third-party risk team will actually ask for, and keep your legal register citing provisions that are still in force. We do not sell toolkits and we do not tell you a certificate makes you compliant with anything.

Talk to a Sterling ISO 27001 consultant

11. Is training included with Sterling’s ISO 27001 consulting?
Every Sterling engagement includes live internal auditor training for your audit team and preferential access to Sterling Academy, with complimentary ISO 27001 awareness training for your people as part of the engagement. Special pricing applies to the wider catalogue — Information Security Essentials, 93 Annex A Controls (ISO/IEC 27002:2022) and Risk Management — through your Sterling consultant. Learners who complete a course and its final exam receive a numbered Certificate of Completion, verifiable online, and the completion records serve as evidence for clauses 7.2 and 7.3 and Annex A control 6.3.

Where to go next

Written and maintained by the ISO 27001 practice at Sterling International Consulting, Philippines. All clause and control references are to ISO/IEC 27001:2022 including Amendment 1:2024. Last updated: 1 August 2026.