How to Read a SaaS Security Page

Most software companies have a security page. Fewer have one that a careful reader can learn from. Between the padlock icons and the phrase "bank-level" there is usually a handful of real facts, and the skill is in finding them. This guide explains how to read a security page as a buyer, a reviewer or someone compiling a comparison: what to look for, what each common term means, and which questions to ask when the page is silent.

It is written in a reference style. Each section defines a term, explains what it does and does not establish, and ends with a check you can apply.

Start with scope

Before any detail, find the scope. A statement is only as useful as the thing it covers.

An audit report may cover a single product, a single region or a single office, not the whole company. A certification might apply to a data centre rather than the application running in it. A claim that "our infrastructure is certified" says something about the hosting provider's buildings and nothing about the vendor's own software or staff.

Check: for every claim, ask "this applies to what, exactly?" If the page cannot answer, treat the claim as marketing.

Attestations and certifications

Two families of evidence appear most often.

Attestation reports. The best known is SOC 2. An independent auditor examines a company's controls against published criteria and issues a report. A Type I report describes whether controls were suitably designed at a point in time. A Type II report covers a period and says whether the controls operated effectively across it. The report is usually shared on request under a confidentiality agreement. It is sometimes described loosely as a certification, but strictly it is an audit report.

Management system certification. ISO/IEC 27001 is an international standard for an information security management system. An accredited certification body audits an organisation against it and, if satisfied, issues a certificate with a defined scope and an expiry. The certificate's scope statement is the key line: it lists what is included.

Neither proves that a breach cannot happen. Both show that someone independent has looked at the organisation's practices against a recognised yardstick.

Check: is there a named framework, a report type, a period or a certificate scope, and a date? If the page says "compliant with" without any of those, ask what that means.

Encryption statements

Encryption claims are common and often undefined.

• In transit means data is encrypted while it travels between your device and the service, usually through transport layer security. This is now the baseline and not a differentiator.
• At rest means stored data is encrypted on disk. Usually this is done by the hosting provider's storage service and protects against loss of the physical media or improper access to the storage layer.
• End-to-end means only the communicating users hold the keys and the provider cannot read the content. It is a strong claim with real product consequences, such as limited search and no password reset of encrypted data. Be sceptical of the phrase when a product also offers server-side search over your content.
• Customer-managed keys means the customer controls the encryption keys used to protect their data, often through a key management service. It matters most to regulated buyers.

Check: does the page say which of these it means? If the page says only "military-grade", ask for specifics.

Access control

Look for how people get in and what they can do.

• Authentication: passwords, second factors, single sign-on. Single sign-on is commonly offered through standards such as SAML or OpenID Connect; a companion guide on this site covers it.
• Authorisation: role-based access, granular permissions, and audit logs of who did what.
• Internal access: how the vendor's own staff access customer data, whether that access is logged and whether it requires customer consent.

A page that describes customer-facing controls but is silent on internal access has answered half of the question.

Data handling and location

The UK's data protection regulator, the Information Commissioner's Office, publishes guidance on data protection obligations for organisations. For a buyer in the UK or the EU, the key facts are where personal data is stored, who processes it on the vendor's behalf, and the legal basis for any transfers outside the region.

Look for:

• A list of sub-processors, with names and purposes.
• A data processing agreement available for download.
• The hosting region or regions, and whether you can choose.
• Retention and deletion terms: how long data persists after cancellation.

Check: can you find a sub-processor list? A vendor that processes your data should be able to tell you who else does.

Vulnerability handling

Mature security pages describe how problems are found and fixed.

• A contact route for reporting vulnerabilities, preferably a published policy.
• Penetration testing by an independent party, with a frequency and a summary available.
• A statement of how quickly critical issues are patched.
• A history page or advisories section showing real incidents handled in public.

The absence of public incidents is not evidence of perfection; the presence of a calm, factual account of a past incident is often reassuring.

Supply chain and sub-contractors

Modern software is built on other software and other services. The UK's National Cyber Security Centre publishes guidance on supply chain security, which starts from the point that your risk includes your suppliers' risk. When you read a vendor's page, ask the same question of them: what do they depend on, and how do they assess those dependencies?

A page that lists key suppliers and explains how they are reviewed shows that the vendor has thought about it. One that is silent is not necessarily negligent but has given you nothing to check.

Frameworks you may see mentioned

The NIST Cybersecurity Framework is a voluntary framework from the US National Institute of Standards and Technology, organising security work into functions such as identify, protect, detect, respond and recover. A vendor saying it "aligns with" such a framework is describing how it organises its work, not announcing an audit result. Read the verb: aligned, mapped, assessed and certified are very different words.

Reading the page like an auditor

A simple method, which takes ten minutes:

1. Open the page and list every claim. One per line.
2. Tag each claim: control (what they do), evidence (what proves it) or slogan.
3. For each control, find the evidence. A link, a report, a date.
4. Mark the scope. Which product, region and period?
5. Mark the date. When was this last updated?
6. List what is missing. Sub-processors, incident history, internal access, key management.
7. Send the missing items as questions.

A vendor who answers the questions promptly and in writing is usually a better risk than one with a prettier page.

Questions to send

• Which independent reports do you hold, for what scope and period, and can we read the latest?
• Where is customer data stored and can we choose the region?
• Which sub-processors handle our data and for what?
• How do your staff access customer data and is that access logged?
• How long is data kept after we leave, and how is deletion confirmed?
• How do we report a vulnerability?
• What was your last significant incident and what changed afterwards?

For vendors: writing a page that deserves to be read

If you are on the other side, the same list works as a template. State scope, name evidence, give dates, link documents, publish the sub-processor list and offer the questionnaire. Resist slogans. A security page that reads like a fact sheet is both more honest and quicker to approve in a procurement process.

Three worked readings

Abstract advice is easier to apply with examples, so here are three invented but typical sentences and how a careful reader would treat each.

"We are SOC 2 compliant." The word compliant is carrying too much. A reader should ask whether this means a Type I or Type II report, which trust criteria were in scope, what period it covers and whether the report is available. If the answer to every question is a link and a date, the sentence is probably honest. If the answer is silence, the sentence is a slogan.

"All data is encrypted." Encrypted where, and with whose keys? If the page goes on to say that the hosting provider encrypts storage and that transport is protected, the claim is true but modest. If it hints at more, such as "only you can read your data", ask directly whether the vendor can decrypt content, because the answer determines what features such as search, support access and recovery are possible.

"Hosted in a world-class data centre." This tells you about a landlord, not a tenant. The useful facts are the region, the provider and whether the vendor has its own audit coverage over the layers it controls.

Practising on other people's pages is the fastest way to get good at this. Pick three products you already use, write down the claims on each security page, and tag them as control, evidence or slogan. You will quickly see which vendors write for readers and which write for a design review.

What a good answer looks like

When you send your questions, you are looking for a particular shape of reply: specific, dated and willing to name limits. "We hold a Type II report for the period ending in the spring, covering the production application and its supporting infrastructure; we can share it under a confidentiality agreement" is a good reply. So is "We do not currently hold an independent report; here is our questionnaire and a description of our controls." The second reply is less impressive, but it is the same quality of honesty, and a buyer with modest requirements may be well served by it.

The worst replies are the ones that restate the page in longer words. If the answer does not contain a name, a date or a document, send one polite follow-up and then weigh the silence as information.

Summary

Read a security page by separating claims from evidence, and evidence from scope. Know the difference between an attestation report and a certificate, between encryption in transit, at rest and end to end, and between aligned and audited. Check dates, find the sub-processor list and send questions for anything missing. The page that survives this treatment is the one worth trusting.