The four quality tiers for business critical software

Quality is not one thing, it is four tiers

When a business commissions software it truly depends on, software where a failure means money lost, a law broken or customers gone, the hardest question is rarely which framework to choose. It is what the word "quality" is even supposed to mean, because almost every supplier uses it to mean something different, and a fair few use it to mean nothing you can check.

You will know the phrases. "Bank level security." "Fintech grade." "Enterprise ready." They are built to borrow the prestige of regulated finance while saying nothing you could test. What I want to do here is take that word apart and rebuild it as four distinct tiers, so you can separate marketing noise from the things that actually keep a system on its feet.

The four tiers are these: being a regulated financial institution, holding the certifications a serious vendor earns, meeting the laws that apply to you, 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 reach the first, choose carefully about the second, cannot escape the third, and stand or fall on the fourth. The businesses in the examples 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 an authorised, supervised financial institution. This is a tier a client might occupy. A developer never becomes the authorised entity, and anyone who suggests they are one is misleading you.

If you take and hold customer money, move it on their behalf, or issue electronic money, you almost certainly need authorisation. Across the European Union the framework is the second Payment Services Directive, Directive (EU) 2015/2366, commonly called PSD2.¹ It carries a real price of entry. A payment institution must hold initial capital of at least €125,000 for the core payment services, €50,000 where it only provides payment initiation, and €20,000 where 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 fall under 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 beginning. Authorisation brings a fit and proper test for directors, ongoing own funds rules, regulatory reporting, safeguarding of customer money and a compliance function, all under a supervisor's eye. In Ireland that supervisor is the Central Bank of Ireland; in Austria it is the Financial Market Authority (FMA), in Germany the Federal Financial Supervisory Authority (BaFin) with the Bundesbank, and in the United Kingdom the Financial Conduct Authority (FCA).⁴⁵⁶⁷ The rules are being rewritten, too: 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 authorisation requirement, and if you do not, no rival is more "bank level" than you for claiming 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 authorisation. I retire the phrase "near fintech" for exactly 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 sits, so read this part 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 for you. 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 case. It is a System and Organization Controls report defined by the American Institute of Certified Public Accountants (AICPA) and measured against its Trust Services Criteria.⁹ A SOC 2 report can be issued only by a licensed certified public accountant firm, under the AICPA attestation standards, which is why careful practitioners 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 merely a snapshot. I set out 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 into the cloud world: ISO/IEC 27017 for cloud security and ISO/IEC 27018 for protecting personal data in public clouds.¹¹¹² The line is just as bright here. ISO writes the standard but certifies no one. An accredited certification body does that, and ISO says as much 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 since 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, well 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, year after 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 neither optional nor 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 in the room.

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, enforced in Ireland by the Data Protection Commission, 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 the checkout.¹⁸

Accessibility sits here now as well. 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, and Ireland through its own transposing regulations.²⁰²¹ 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, stacks 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 disappear.

Tier 4: the engineering discipline that actually produces reliability

The fourth tier needs no authorisation 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 can humanly be arranged, nothing quietly goes 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 rest 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 merely 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

A worked example: a Cork firm taking card payments

A Cork 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 Ireland 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 authorisation. If it later launched a wallet that stored customer balances, that would change, and it would need to speak to the Central Bank of Ireland 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 Irish and Dutch customers, overseen in Ireland by the Data Protection Commission. 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 Cork 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 far lower cost, plan than a blanket demand for bank level everything.

Which tier do you actually need?

For most businesses the answer has 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 a vague worry. 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 spooked 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 far 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 on your feet is the one nobody hands you a certificate for.