Writing the Security Page Nobody Reads

Who actually reads it

Not many people, and the ones who do matter.

A business customer completing due diligence. Somebody deciding whether to enter payment or personal details. A prospective client's technical person. Occasionally a researcher who has found a problem and is looking for somewhere to report it.

Those are all high-value visits, which is why a page with almost no traffic can be worth writing properly.

It is also why the page should be written to be checked rather than to be admired.

Every claim is a commitment

The principle that governs the whole page.

Anything you state is something a customer may rely on, an insurer may read, and a regulator may compare against what you actually do.

Which means the safe approach is to describe practices you can demonstrate, and to leave out anything aspirational.

Saying all data is encrypted, when only the connection is, is inaccurate. Saying we take security seriously is meaningless. Saying we are compliant, without naming a standard you have actually been assessed against, is a claim somebody may ask you to prove.

Write only what would survive somebody asking to see it.

What is worth including

• How data is protected in transit and at rest.
• Where it is stored, at least by region.
• Who has access internally, in general terms.
• How you handle backups.
• What you do about accounts: two-factor, reviews.
• Named subprocessors, or a route to the list.
• How to report a problem, with a real address.

The last is the one most often missing and the one most likely to be used, since a researcher who cannot find a contact frequently posts publicly instead.

The reporting route

Worth treating as the most functional part of the page.

Give a monitored email address, say roughly how quickly you will respond, and state that you will not pursue somebody who reports a genuine issue in good faith.

That last sentence costs nothing and materially changes whether people tell you, because the alternative for a finder is uncertainty about how you will react.

Make sure the address actually reaches somebody who will act, rather than a general inbox where it sits behind sales enquiries.

A small business does not need a formal disclosure programme. It needs an address and a stated willingness to hear from people.

Avoid the compliance shorthand

A specific trap, and it is common.

Naming a standard or a certification implies you have been assessed against it, and using the language loosely is the sort of claim that causes real difficulty in a procurement or a dispute.

Say what is accurate: that you follow good practice in specific named ways, or that a named provider you rely on holds a particular certification, which is a different statement from holding it yourself.

Similarly, describing yourself as compliant with privacy legislation is weaker than describing what you actually do, because the second can be verified and the first is an assertion.

Specific and modest reads as more credible to the audience this page has, which is people who assess these claims for a living.

A worked example

A firm's security page said data was fully encrypted, that they were fully compliant, and that they used bank-level security.

A prospective client's technical reviewer asked three questions: encrypted where, compliant with what, and what does bank-level mean.

None had a good answer, and the page became a problem in a procurement it was meant to support.

They rewrote it in about an hour: connections encrypted, data at rest encrypted by their named hosting provider, backups held separately and tested quarterly, two-factor required on administrative accounts, access reviewed annually, four named subprocessors, and an address for reporting concerns.

Shorter, less impressive, and every line answerable.

The same reviewer approved it without further questions.

Keep it dated and current

Because the page ages badly and silently.

Add a last reviewed date, which tells a reader whether anybody has looked at it recently and is itself a small signal of competence.

Review it whenever you change a significant provider, and add it to the same annual round as your privacy policy so both are handled together.

A page describing a hosting arrangement you left two years ago is worse than no page, because it is a documented inaccuracy rather than an absence.

Where it should sit

A practical point that affects whether it does its job.

Link it from the footer alongside the privacy policy and terms, which is where people look for it.

Link it from any page where somebody is about to enter sensitive information, near the form rather than at the bottom.

And keep it separate from the privacy policy, since the two answer different questions: the policy says what you collect and why, and this page says how it is protected.

Combining them produces a long document where neither question is answered clearly.

The counter-case

Not every business needs this page.

A brochure site with a contact form, holding almost nothing, does not need a security statement, and publishing one invites scrutiny of practices that were never in question.

There is also a version that leaks useful detail: naming specific software versions, describing your network, or listing the tools you use gives an attacker a starting point for no benefit to any legitimate reader.

Describe practices rather than configurations, and stop at the level a customer needs to make a decision.

Write it if you take payments, hold meaningful customer information, or sell to businesses that ask. Otherwise a clear privacy policy is sufficient.

Writing it

1. Write only what you can demonstrate.
2. Say encrypted where, not just encrypted.
3. Avoid naming standards you have not been assessed against.
4. Name your subprocessors or link the list.
5. Give a monitored reporting address.
6. Say you will not pursue good-faith reporters.
7. Date it and review it annually.

Step five is the one that gets used, and step six is what makes people use it rather than posting publicly.

The equivalent for accessibility is covered in an accessibility statement for a small site.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.