The four quality tiers for business critical software

Quality is not one thing, it is four tiers

When a business commissions software it genuinely depends on, software where a failure means lost money, a legal breach or lost customers, the hardest question is not which framework to pick. It is what the word "quality" even means, because almost every supplier uses it to mean something different, and quite a few use it to mean nothing at all.

You will have seen the phrases. "Bank level security." "Fintech grade." "Enterprise ready." They are designed to borrow prestige from a world of regulated finance without saying anything you could check. My job here is to take that word apart and put it back together as four distinct tiers, so you can tell marketing noise from the things that actually keep a system standing up.

The four tiers are: being a regulated financial institution, holding the certifications a serious vendor earns, meeting the laws that bite in our region, and building to the engineering discipline that actually produces reliability. They are not a ladder you climb one rung at a time. Most businesses never touch the first, choose carefully about the second, cannot avoid the third, and live or die by the fourth. The businesses in the examples below are invented. The law, the figures and the sources are footnoted.

Tier 1: being a regulated financial institution

The top tier is not a quality badge at all. It is a legal status: being a licensed, supervised financial institution. This is a tier a client might sit in. A developer never becomes the licensed entity, and anyone who implies they are one is misleading you.

If you take and hold customer money, move it on their behalf, or issue electronic money, you very likely need authorisation. In the European Union the framework is the second Payment Services Directive, Directive (EU) 2015/2366, usually called PSD2.¹ It sets a real price of entry. A payment institution must hold initial capital of at least €125,000 for the core payment services, €50,000 if it only provides payment initiation, and €20,000 if it only runs money remittance.¹ An institution that issues electronic money must hold at least €350,000 under the Electronic Money Directive, Directive 2009/110/EC.² Crypto asset firms have their own regime, the Markets in Crypto Assets Regulation, Regulation (EU) 2023/1114, which has applied in full since 30 December 2024.³

Capital is only the start. Authorisation brings a fit and proper test for directors, ongoing own funds rules, regulatory reporting, safeguarding of customer funds and a compliance function, all overseen by a supervisor. In Austria that supervisor is the Financial Market Authority (FMA), in Germany it is the Federal Financial Supervisory Authority (BaFin) together with the Bundesbank, and in the United Kingdom it is the Financial Conduct Authority (FCA).⁴⁵⁶ The rules are being rewritten: in June 2023 the European Commission proposed a third directive and a directly applicable Payment Services Regulation to replace PSD2.⁷

So Tier 1 answers a yes or no question about the business, not a quality question about the code. If you become a payment institution, no amount of good engineering removes the licence requirement, and if you do not, no competitor is more "bank level" than you by saying so. When I build a payment flow for a client, I build the software to the standard the regulator expects, but the client, not me, holds any licence. I retire the phrase "near fintech" for this reason. It sounds like a status and means an engineering standard, and the two should never be blurred.

Tier 2: the certifications a serious vendor earns

The second tier is where most of the confusion lives, so this is the part to read slowly.

A certification such as SOC 2, ISO/IEC 27001 or PCI DSS is a statement about an organisation, issued by an accredited independent third party that the organisation commissions and pays. It is not something a developer holds, hands over with the code, or ticks off on your behalf. My job is to build software that complies and to prepare you for the audit. The certificate is yours to earn, from someone who is not me.

SOC 2 is the clearest example. It is a System and Organization Controls report defined by the American Institute of Certified Public Accountants (AICPA), measured against its Trust Services Criteria.⁸ A SOC 2 report can only be issued by a licensed certified public accountant firm, under the AICPA attestation standards, which is why practitioners are careful to call it an attestation rather than a certification.⁸ A Type II report covers how the controls operated across a period, usually six to twelve months, not just a snapshot. I cover the mechanics in my deep dive on SOC 2 Type II.

ISO/IEC 27001 is the international standard for an information security management system, current edition 2022.⁹ Two siblings extend it for the cloud world: ISO/IEC 27017 for cloud security and ISO/IEC 27018 for protecting personal data in public clouds.¹⁰¹¹ Here too the line is bright. ISO writes the standard but does not certify anyone. An accredited certification body does that, and ISO says so on its own site.¹² The developer builds the management system and the controls. The client appoints the certification body.

PCI DSS, the Payment Card Industry Data Security Standard, applies to any business that stores, processes or transmits cardholder data. The current version is 4.0.1, published by the PCI Security Standards Council in June 2024, with its newer requirements in force from 31 March 2025.¹³ How you validate depends on how much card traffic you carry: a smaller merchant may complete a self assessment questionnaire, while the largest undergo an onsite assessment by a Qualified Security Assessor.¹³

Two honest points follow. First, building to a named standard adds real cost to the build itself, long before any certificate. Audit trails, access controls, documented change management and evidence collection are work, and that work is in the price whether or not you ever call an auditor. Second, the auditor is a separate invoice you pay directly, every year, to keep the certificate live. ISO 27001, PCI DSS and the OWASP Application Security Verification Standard each deserve their own article, and those are coming. For now, SOC 2 is the worked example of what a Tier 2 certification really involves.

Tier 3: the laws that bite in our region

The third tier is not optional and not a badge. These are obligations that apply to you by law because of what you do and where you do it, whether or not any auditor is ever involved.

Four matter most for a software business serving Europe. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025, and it governs operational resilience for EU financial entities and reaches their information and communications technology providers through contract, so if your client is a bank or an insurer, DORA clauses will land on you.¹⁴ NIS2, Directive (EU) 2022/2555, sets cyber security duties for cloud services, managed service providers and online marketplaces, with incident reports on a 24 hour clock. I wrote a full guide to who NIS2 covers and what it asks.¹⁵ The General Data Protection Regulation, Regulation (EU) 2016/679, governs personal data for almost everyone, and I covered the supplier side of it in vetting vendors before they undermine your compliance and the upside in treating the GDPR as a strategic advantage.¹⁶ Strong customer authentication under PSD2 and its technical standard, Delegated Regulation (EU) 2018/389, decides how a customer must prove who they are at checkout.¹⁷

Accessibility now sits here too. The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025 and names consumer facing ecommerce among the services it covers.¹⁸ Member states have turned it into national law: Germany through the Barrierefreiheitsstärkungsgesetz and Austria through the Barrierefreiheitsgesetz, both in force from the same date.¹⁹²⁰ The practical target is the Web Content Accessibility Guidelines 2.1 at level AA, a W3C standard.²¹ I set all of this out in my article on the accessibility requirements for EU ecommerce and SaaS, and the Cyber Resilience Act, which I treat in its own article, adds product security duties on top.

The honest framing of Tier 3 is that you do not choose it. You find out which of these laws apply to your business, and you comply, or you carry the risk of a fine. Good engineering makes compliance less costly and provable, but it does not make the obligation go away.

Tier 4: the engineering discipline that actually produces reliability

The fourth tier needs no licence and no certificate, and it is the only one my quality claim rests on. It is the engineering discipline that produces software where, as far as it is humanly arrangeable, nothing can quietly go wrong. It is what the other three tiers assume underneath them, and it is where good suppliers are told apart from loud ones.

It has six parts, and none of them is exotic.

Immutable audit trails. Every change to money, to permissions or to customer data leaves a record that cannot be edited after the fact, so you can always answer who did what, and when.

Correctness by construction. Money is tracked in a double entry style so the books must balance. Operations are made idempotent, which means the same request arriving twice, after a timeout or a double click, never charges the customer twice. Reconciliation jobs run on a schedule and prove that the numbers in your system still agree with the numbers at the payment provider.

Zero trust and least privilege. Data is encrypted in transit and at rest, secrets live in a managed store rather than in the code, access is granted by role and reviewed, and the duties that should not sit with one person are separated.

Change management. Approvals, a release register that records what shipped and when, and the ability to prove it later. I treat this as the heart of provable quality, and set it out in evidencing compliance with release registers and security testing on every release.

Resilience. High availability so a single failure does not take the service down, and disaster recovery with a stated recovery time objective, the longest you can be down, and a recovery point objective, the most data you can afford to lose. Backups are tested by restoring them, not just taken.

Independent assurance. Exhaustive automated tests written first, through test driven and behaviour driven development, and on top of that an independent penetration test before a system faces the internet. Software built this way is also easier to insure, because the insurer can see the discipline behind it.

This is the tier I mean when I say I build business critical software. I do not say I am certified to it, because it is a practice, not a stamp. I say it is the rigour I build to, and I can show you the release register and the penetration test report that prove it.

The four tiers at a glance

Tier	What defines it	Who it is about	Who issues or enforces it	My role
1. Regulated institution	A legal licence to handle money or issue electronic money	The business itself	A financial supervisor (FMA, BaFin, FCA)	Build to the regulator's standard, and the client holds the licence
2. Certification	An audited statement about an organisation's controls	The organisation	An accredited third party the client pays (a CPA firm, a certification body, a QSA)	Build to comply and prepare you for the audit, never hold it myself
3. Law	A legal obligation triggered by what you do and where	The business, by activity	Regulators and courts	Build so compliance is provable, and help work out what applies
4. Engineering discipline	The practice that makes failure rare and recoverable	The software and the team	No one, it is shown, not awarded	This is the standard I build to, and can evidence

A worked example: a Leeds firm taking card payments

A Leeds company sells a subscription box and has grown to the point where it takes card payments directly and holds names, addresses and order histories for tens of thousands of customers across the UK and the Netherlands. Which tiers actually touch it?

Tier 1: none. It sells its own goods and never holds customer money on anyone's behalf, so it is not a payment institution and needs no licence. If it later launched a wallet that stored customer balances, that would change, and it would need to talk to the FCA first.

Tier 2: PCI DSS, yes, because it handles cardholder data, and the level of validation depends on its card volume. SOC 2 or ISO 27001, only if a business customer or a partner demands it in a contract. Nobody is forcing a certificate on a direct to consumer shop today, so it should treat these as a sales decision, not a reflex.

Tier 3: the GDPR certainly, because it holds personal data of UK and Dutch customers. The European Accessibility Act, because it sells to Dutch consumers online. NIS2, almost certainly not, because a shop selling its own goods is not an online marketplace. DORA, no, because it is not a financial entity and has no financial clients.

Tier 4: all of it. This is where the money is actually protected, the checkout does not double charge, the customer data is encrypted, and a bad deploy can be rolled back and explained. Everything the shop's reputation rests on lives in Tier 4.

So the honest answer for this Leeds firm is: build to Tier 4, comply with the Tier 3 laws that apply, validate PCI DSS at the right level, and reach for a Tier 2 certificate only when a customer actually asks. That is a very different, and much lower cost, plan than a blanket demand for bank level everything.

Which tier do you actually need?

For most businesses the answer is the same shape. You need Tier 4 engineering without exception, because it is what makes the software trustworthy at all. You need whichever Tier 3 laws apply to your activity and your customers, which you cannot opt out of. You need a Tier 2 certification only when a customer, a sector or a procurement process genuinely requires one, and you should pursue it deliberately rather than as insurance against vague anxiety. And you reach Tier 1 only if you yourself become a regulated institution, which is a strategic decision with a capital requirement attached, not a technical upgrade.

The mistake I see most often runs in one direction: a business is sold a certificate it does not need, or frightened by a phrase like "fintech grade", while the Tier 4 engineering that would actually prevent its outages is quietly skipped. A certificate on the wall and a system that double charges customers is the worst of both worlds. Spend on the tier that removes the risk you actually carry.

How to read a supplier's claims

Because the words cost nothing, learn to read past them. When a supplier says "SOC 2 compliant", ask to see the report and check whose controls it covers. A hosting provider's SOC 2 covers the data centre, not the application your supplier built on top of it, and those are entirely different things. When a supplier says "certified", ask who the independent auditor or certification body was, and when the certificate expires, because a real one has both. When a supplier says their software is secure and resilient, ask for the two artefacts that prove Tier 4: the release register that shows what shipped and when, and the most recent penetration test report with its findings and fixes. A supplier building to the discipline will have both ready. A supplier borrowing prestige will change the subject.

The same questions protect you in your own supply chain. Your hosting, your payment provider and your email service each sit in some tier of their own, and under both NIS2 and the GDPR their weaknesses can become your liability. Write down which controls are theirs and which are yours before you need to know.

The honest position

I am not an auditor, and I do not hold SOC 2, ISO 27001 or PCI DSS, because those belong to organisations and are issued by independent parties that a client commissions and pays. I am not a regulated financial institution, and I will never imply that I am. What I offer is Tier 4: the engineering discipline that makes software reliable, built so that the Tier 3 laws you face are provable and any Tier 2 certificate you choose to pursue is within reach rather than a rebuild away. I would rather tell you plainly which tier you need, and which you do not, than sell you a stamp.

If you are not sure which tiers reach your business, or whether a supplier's "bank level" claim means anything, book the free workshop and I will map it with you, and the first two weeks of the work are on me.

What to do now

Work through these in order. First, list what your software actually does: does it hold money, process cards, hold personal data, serve consumers, serve financial clients? Second, read off the Tier 3 laws that follow from that list, and the Tier 2 certifications any customer actually demands. Third, be honest about whether you belong in Tier 1 at all, because most businesses do not. Fourth, whatever the answers above, commit to Tier 4, and ask your supplier, or yourself, to show the release register and the penetration test. The tier that keeps you standing up is the one nobody hands you a certificate for.

Footnotes

1. European Parliament and Council, Directive (EU) 2015/2366 on payment services in the internal market (PSD2), Articles 5, 7 and 11, Official Journal L 337, 23 December 2015, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015L2366 ↩ ↩²

2. European Parliament and Council, Directive 2009/110/EC on the taking up, pursuit and prudential supervision of the business of electronic money institutions, Article 4, Official Journal L 267, 10 October 2009, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009L0110 ↩

3. European Parliament and Council, Regulation (EU) 2023/1114 on markets in crypto assets (MiCA), Article 149 on application dates, Official Journal L 150, 9 June 2023, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R1114 ↩

4. Financial Market Authority Austria, Licencing and registration of payment services, fma.gv.at, accessed 13 November 2026, https://www.fma.gv.at/en/financial-service-providers/payment-institutions/licencing-and-registration-of-payment-services/ ↩

5. Bundesanstalt für Finanzdienstleistungsaufsicht, Payment services and PSD2, bafin.de, accessed 13 November 2026, https://www.bafin.de/EN/ ↩

6. Financial Conduct Authority, Payment Services Regulations 2017 and Electronic Money Regulations 2011, fca.org.uk, accessed 13 November 2026, https://www.fca.org.uk/firms/payment-services-regulations-e-money-regulations ↩

7. European Commission, Proposal for a Regulation on payment services in the internal market, COM(2023) 367 final, 28 June 2023, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0367 ↩

8. American Institute of Certified Public Accountants, System and Organization Controls: SOC Suite of Services, and the Trust Services Criteria, aicpa-cima.com, accessed 13 November 2026, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services ↩ ↩²

9. International Organization for Standardization, ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection, Information security management systems, Requirements, iso.org, https://www.iso.org/standard/27001 ↩

10. International Organization for Standardization, ISO/IEC 27017:2015 Code of practice for information security controls for cloud services, iso.org, https://www.iso.org/standard/43757.html ↩

11. International Organization for Standardization, ISO/IEC 27018:2019 Code of practice for protection of personally identifiable information in public clouds, iso.org, https://www.iso.org/standard/76559.html ↩

12. International Organization for Standardization, Certification, iso.org, accessed 13 November 2026, https://www.iso.org/certification.html ↩

13. PCI Security Standards Council, PCI DSS v4.0.1 and the official document library, pcisecuritystandards.org, accessed 13 November 2026, https://www.pcisecuritystandards.org/document_library/ ↩ ↩²

14. European Parliament and Council, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), Article 64 on application from 17 January 2025, Official Journal L 333, 27 December 2022, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554 ↩

15. European Parliament and Council, Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS2), Official Journal L 333, 27 December 2022, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555 ↩

16. European Parliament and Council, Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩

17. European Commission, Delegated Regulation (EU) 2018/389 supplementing PSD2 with regard to regulatory technical standards for strong customer authentication, Official Journal L 69, 13 March 2018, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389 ↩

18. European Parliament and Council, Directive (EU) 2019/882 on the accessibility requirements for products and services (European Accessibility Act), Article 31 on application from 28 June 2025, Official Journal L 151, 7 June 2019, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882 ↩

19. Federal Republic of Germany, Barrierefreiheitsstärkungsgesetz (BFSG), in force 28 June 2025, gesetze-im-internet.de, https://www.gesetze-im-internet.de/bfsg/ ↩

20. Republic of Austria, Barrierefreiheitsgesetz (BaFG), BGBl. I Nr. 76/2023, in force 28 June 2025, Rechtsinformationssystem des Bundes, https://ris.bka.gv.at/eli/bgbl/I/2023/76 ↩

21. World Wide Web Consortium, Web Content Accessibility Guidelines (WCAG) 2.1, W3C Recommendation, w3.org, https://www.w3.org/TR/WCAG21/ ↩