A small SaaS team can cover most risk with automated checks on every change, a short threat model for each major feature, a quarterly review of findings and scope, and an annual independent penetration test. Add more only when your size and customers demand it.
Per commit or pull request
Automated checks that cost seconds:
- Dependency scanning against known vulnerabilities.
- Secret detection.
- Static analysis for obvious code flaws.
- Linting for infrastructure files.
Keep the checks quick and the failure rules clear. A scan nobody trusts gets ignored. Decide which severities block a merge and which only warn. Safeguard offers SBOM and dependency scanning, secret and code checks, and policy gates for this layer, and a free scan is available at https://gold.safeguard.sh/scan.
Per feature
When you design something that handles data, identity or money, hold a short threat model. The OWASP guidance says to do it early, as part of the normal development lifecycle, and not as an add on. One hour, the four questions, and tickets for what you find.
Add abuse cases to your acceptance criteria. Ask what a malicious user would try with this feature.
Per release
- Run your web application against a checklist. The OWASP Web Security Testing Guide is a free testing resource, with v4.2 listed as the current stable version.
- Check that new endpoints have authorisation tests.
- Review new third party components and their licences and vulnerabilities.
- Read the diff of infrastructure changes.
Monthly
- Review open vulnerability findings and aging.
- Check your security contact channel and its mailbox.
- Look at new dependencies added across the month.
Quarterly
- Revisit threat models for services that changed.
- Review the scope of your disclosure policy and add systems, if you have capacity.
- Run a restore test for backups.
- Update your risk list and fix targets.
- Check that your security.txt file has not expired.
Annually
- Commission an independent penetration test with a defined scope. NIST SP 800-115 is a general reference on planning and conducting technical security tests.
- Retest fixes.
- Review your disclosure policy.
- Run an incident response exercise.
- Review access to production and cloud accounts.
What to skip at first
- A bug bounty, until you can fix reports quickly. OWASP recommends mature disclosure and fix processes first.
- Adversary emulation, until you have monitoring and someone to respond.
- Tools you cannot staff. A tool without an owner produces a list nobody reads.
Adjust for triggers
Run extra testing after:
- A major architecture change.
- A new integration with a third party.
- A security incident.
- A customer requirement for evidence.
- A change in the data you hold.
Keep records
For each activity, record date, scope, who did it, and the follow up status. Customers and auditors often ask for this, and it helps you see gaps.
Quick check
Is one pentest a year enough?
It depends on how fast you change and what you hold. Many small teams pair an annual test with automated checks and extra tests after major changes.
What if we have no security person?
Choose one engineer as owner, keep the automated layer strong, and bring in outside help for threat modeling and testing.
Sources
- OWASP Threat Modeling Cheat Sheet
- OWASP Web Security Testing Guide
- NIST SP 800-115
- OWASP Vulnerability Disclosure Cheat Sheet
Last reviewed: 19 October 2026.
