Who it is for
- →Teams that ship weekly or faster
- →Products where AI assistants write a meaningful share of the code
- →Companies answering vendor questionnaires and SOC 2 audits every quarter
- →Leadership that wants evidence, not a date
How it runs
- Continuous
Every release, every rule
Each rule from your audit is re-proven against the live product on every release and comes back holding or broken. A regression shows up on the release that introduced it.
- Monthly
New patterns
As the public record grows, so does the pattern library. New scenarios are added to your rule set and tested without a new engagement.
- Quarterly
Researcher review
A named researcher reviews what changed in your product and attack surface, and adjusts scope and rules with your team.
- On demand
Evidence
One page for the board and a control-by-control map for auditors and customers, generated from live test results.
What you get
- 01
- Live rule statusEvery plain-English rule, holding or broken, with the last test time.
- 02
- Release reportAfter each release, every rule re-proven; a broken rule reaches your engineers with root cause and priority.
- 03
- Evidence on demandSOC 2, ISO 27001 and customer questionnaire answers backed by test results, not screenshots.
- 04
- A named researcherOne person who knows your product end to end.
Questions
What is continuous security assurance?
Continuous security assurance means every security control is expressed as a testable rule and re-tested automatically on each release, so security status is always current.
Does it replace SOC 2 or a pentest?
It produces the evidence SOC 2 and vendor reviews ask for and reduces what an annual pentest can find, but it is not a certificate. Your auditor receives a control map backed by live test results.
How does it handle AI‑written code?
Rules test the behaviour of the deployed product, so it does not matter who or what wrote the code. A generated handler that skips an ownership check fails the same rule a human-written one would.
How does continuous assurance fit our release process?
MATT re-proves every rule against a staging or production deployment on each release, with read-only access, and reports each one as holding or broken. Your pipeline and your release decisions stay with your team. Teams that want wider coverage run MATT on developer machines as well, so each rule is also checked as the code is written.
Does MATT change our code on its own?
In the first engagement every fix is written with your team and approved by your engineers, so the rules and the threat model are understood first. After that, fixes can be applied automatically where you allow it, with a human approving whatever you decide needs one.