Okay, But Actually… A Certification Logo Does Not Cover Your Whole Business

In a discussion about custom software, someone listed ISO certification, card-payment rules and penetration testing as reasons a growing business might prefer an established product. Fair points. But the way that list gets thrown around, you'd think clicking “subscribe” certifies the customer's whole business.

Say a business buys an online booking system. The supplier has an ISO/IEC 27001 certificate. A payment provider handles card payments. The booking system has had a security test. Those are all good things to ask about.

Now the business gives every employee admin access and regularly downloads customer details into a spreadsheet that the whole team can open. The supplier's certificate has been asked to do quite a lot of work here. Nobody audited those choices.

Start with the ISO certificate

ISO/IEC 27001 is about how a company manages information security: looking at risks, putting safeguards in place and reviewing them. An independent company can audit that work and issue a certificate. ISO itself does not issue certificates.

The certificate describes which parts of the supplier's business were audited. A supplier might sell several products, while its certificate covers the work behind only some of them. Before treating the certificate as reassurance, ask whether it covers the service you plan to use. The badge on a website does not answer that.

I am not expecting anyone to learn the standard over lunch. Ask for the certificate, check that it names the right company and see whether it is current. If you cannot tell whether your service is covered, ask the supplier. The answer should be easier to find than the sign-up button.

Buying software from a certified supplier does not give your own business an ISO certificate. It also does not settle what happens to customer information after someone downloads it. If the export lands in a spreadsheet that everyone can open, your business has to decide who should have access and where that file belongs.

Card payments are a separate question

PCI DSS is a set of rules for protecting card details. When I build software that takes payments, I usually connect it to a payment service rather than have the new app collect card numbers itself. That might be Stripe Checkout, Stripe Elements, Authorize.net Accept Hosted, or the provider the client already uses, once we have checked how its checkout works.

Sometimes the customer goes to the provider's checkout page. Sometimes the card fields appear within the business's website but are supplied by the provider. In both cases, the aim is for card numbers to go to the payment provider without passing through the business's own app. The app can still create the order and receive confirmation that it was paid. A custom booking system does not require a homemade card-payment system.

The PCI Security Standards Council says this can reduce a business's card-security work, but does not remove its responsibilities. So I would still check which payment service is being used, who supplies the card fields and what the business must do to use it safely. When someone says “we use Stripe,” I ask them to show me the checkout.

What was tested?

A penetration test is when security specialists are hired to look for ways into software. If a supplier has done one, good. I would ask when it happened and what part of the product they tested. A check of the public website does not tell me whether they also checked the area where staff see customer records.

The UK's National Cyber Security Centre explains that a test reflects the software as it stood at the time. A supplier can release new features after the test. A business can also add its own connection to a customer database. The earlier test will not tell us whether that new connection is safe.

A supplier may have good reasons not to publish a detailed report that shows exactly where its weaknesses were. A short summary can still say what was tested, when, and whether serious problems were fixed.

Buying and building both have boundaries

An established product may come with a security team, regular testing and documents a customer can inspect. I like that. A custom tool can also use an established payment provider and hosting service. Then the business and its developer look after the parts they build. Repeating “ISO, PCI, pen test” does not settle which option fits.

Before choosing, I would put these questions to the suppliers and the business team:

• Can we see the current certificate, and does it cover the service we will use?
• What does the supplier look after, and which settings are up to us?
• How will our card payments work, and which parts belong to the payment provider?
• Which parts were tested, when, and were the problems fixed?

Those answers might favour an existing product or a small custom tool. Either way, someone needs to find out who can see customer records and where exported lists end up.

The supplier's documents would make me more comfortable buying its software. If the sales pitch uses those documents to skip the question of why every employee has admin access, I am going to ask it again.