Level 1
Point-in-time testing
Annual pentests and periodic scans give you a snapshot. It starts ageing as soon as the product changes.
Continuous Product Security Assurance
Assurance means being able to answer a customer’s question with evidence from the product you are shipping now, not just a stack of old reports.
What an audit cannot tell you
An audit checks whether the organisation has the right processes and controls. That matters, but it does not tell you whether tenant isolation survived last week’s refactor.
Assurance stays close to the product. It asks whether the properties we care about still hold in the software we are about to ship.
For a B2B vendor selling to larger customers, this is usually the question behind the questionnaire and the contract language.
Start with what must stay true
Start by naming what must remain true. For most B2B SaaS products that means tenant isolation, so that one customer cannot reach another’s data, and authorisation, so that every request is checked against the caller’s rights. It also means identity and session boundaries, where SSO and session lifetime behave as promised.
Sensitive data is stored and transmitted as intended, and integrations cannot be abused. Incidents and changes must not silently weaken any of this.
Where teams usually start
Level 2
Continuous checks
Automated checks run on every change, but they only cover the problems those tools can see.
Level 3
Regression and evidence
Important properties have checks attached to them, and the result stays current enough to show a customer.
Most vendors start with the first level and add some automated checks in CI. The next useful step is evidence tied to a property that is current and reproducible, rather than another tool to maintain.
Evidence someone else can trust
Not every report answers a customer’s question. The useful evidence has a few practical qualities.
Current, not historical
A pentest from two years ago says little about the build you are shipping today.
Tied to a property
“We passed a scan” is weak. “These checks cover tenant isolation, and they pass on this build” is something you can defend.
Reproducible
Someone else should be able to run the check and get the same answer. Otherwise it is an assertion, not evidence.
Owned
Someone owns the check and notices when the product has changed enough to make it irrelevant.
A rhythm the team can keep
The work continues after the first dashboard is complete. A simple rhythm keeps the checks useful as the product changes.
Every change
Automated checks gate the pipeline.
Every release
Security-critical properties are verified.
Every quarter
Requirements and threat models are revisited.
Every incident
The root cause becomes a new regression check.
Every customer review
Evidence is pulled from the system, not rebuilt by hand.
Common questions
Does continuous assurance mean more tooling?
Not necessarily. It means deciding which properties matter, defining checks for them, and keeping the evidence current. Some checks will be automated, some will be targeted manual tests, and some will be design reviews.
Can a small team sustain this?
Yes, if the scope is honest. A handful of well-chosen properties with reliable checks is worth far more than broad coverage nobody maintains. Start with tenant isolation and authorisation.
How does this relate to ISO 27001 and SOC 2?
They are complementary. Compliance frameworks describe organisational controls; continuous assurance shows that the product itself behaves securely. Many teams reuse assurance evidence to satisfy auditor and customer requests.
How often should evidence be refreshed?
Automated checks run continuously. Targeted verification runs on each release that touches a security-critical area. The underlying requirements and threat models should be revisited at least quarterly, or whenever the architecture changes.
Related resources
Product Security vs Application Security
Application Security finds and fixes bugs. Product Security keeps the security properties of your product true over time. Here is the practical difference.
Read moreWhat is Product Security Engineering?
Product Security Engineering turns security requirements and threat models into engineering work that ships and stays fixed.
Read moreProduct Security Assessment
A one-week Product Security Assessment that shows where your security effort is fragmented and what deserves investment next.
Read moreStart with the Product Security Assessment
One week at a fixed fee, and a clear picture of where your Product Security effort is fragmented and what deserves investment next.