Security you can evidence, rather than security you assert
“Is it secure” has no answerable form. Security is not a property a system has; it is a relationship between a system and an adversary, and the adversary is not standing still.
What can be answered is narrower and considerably more useful: which controls are in place, whether they were operating, and what they would and would not stop. That is the claim an organisation can actually make and support.
Establishing it is what the security half of an it audit services engagement does, and the reframing changes what gets built as much as what gets reported.
The five controls that carry most of the weight
For an ordinary software business, most realistic compromise is prevented by a short list. None of it is exotic.
Multi-factor authentication everywhere it can be turned on. Credential reuse and phishing are the common routes in, and this closes most of both. The cost is an afternoon and some complaining.
No standing administrative access. Access granted when needed, expiring automatically. The permanent administrator account nobody uses is the one that gets taken.
Patching with a stated window. Not “we keep things up to date” — a period within which a published vulnerability gets addressed, and a record of whether that period was met.
Backups that have been restored. Ransomware turns a backup question into a survival question, and an untested backup is a belief.
Logging that is retained and reviewed. Not to catch an attack live, but so that after an incident the question “what did they reach” has an answer.
An organisation with those five operating is meaningfully harder to damage than one with an expensive tool and none of them.
Why the tool-first approach disappoints
Security products are easier to buy than controls are to operate, and they produce a visible artifact — a dashboard, a report, a line item. Controls produce nothing except the absence of a problem.
So spending drifts toward tools while access reviews go unperformed, and the organisation ends up with detection capability it cannot staff, monitoring nobody reads, and an administrative account belonging to someone who left in March.
The order that works is unglamorous: operate the five, then buy tooling to make operating them cheaper.
What “evidence” means here
The distinction that matters is between a description and an artifact.
“We review access quarterly” is a description. A dated export of the access list, with a note of what was removed, is an artifact. The first cannot be checked; the second can be handed to someone who was not there.
Building systems so the artifact is a by-product of the action — access granted through a request that is itself the record, changes deployed through a pipeline that logs them — is the difference between a security programme that survives scrutiny and one that generates a fortnight of work whenever someone asks.
The claim you can honestly make
Not “our platform is secure.” Something like: authentication requires a second factor; administrative access is time-bound and reviewed quarterly, most recently in March; published vulnerabilities in dependencies are addressed within thirty days; backups were last restored in February; access logs are retained for a year.
Every clause there is checkable and none of them claims safety. That is a stronger position in a customer security review than any adjective, and it is the only version that survives contact with someone technical.
Where to start if none of it exists
In order, because the order reflects return rather than difficulty.
Turn on multi-factor authentication. Export the production access list and remove everyone who should not be there. Restore a backup and write down the date. Those three take a week between them and remove most opportunistic risk.
Where this framing has limits
It says nothing about a determined, well-resourced adversary. The five controls raise the cost of opportunistic compromise substantially and are not designed for a targeted attacker with time and money. If that is your threat model, this is a floor rather than a programme, and you need people whose whole job this is.
It also does not cover the human routes — a convincing phone call to someone in finance is not addressed by any of the above, and social engineering accounts for a large share of real incidents.
And I should be plain about my own boundary: I can establish which controls are in place and build the systems that make them operable. I am not a penetration tester and do not offer assurance that a system resists attack. Those are different disciplines, and conflating them is how buyers end up with an audit when they needed an attacker.
Related reading: protecting sensitive information covers the data-specific controls, information systems covers the inventory every one of these controls is applied per-system, and what a compliance audit proves covers the gap between compliant and secure.