A security validation SOP tells you, before real customers hand over their data, whether an attacker could read it, change it or take your product offline, and a first pass takes one to two weeks. You list the threats, run free scanners, try to break your own login and access rules, and fix what matters most. One leaked customer list can end a startup that has no lawyers and no cash reserve. The result is a short findings log you can also show the first enterprise buyer who sends a security questionnaire.

What is the security validation SOP and when should you use it?

Security validation is a structured check that your product protects data and accounts at the level your customers expect. It combines three things: a threat model (what could go wrong), automated scans (what tools find in minutes) and manual tests (what only a human finds, such as one customer seeing another customer's records). This SOP covers your application. Money-handling rules sit in the financial compliance validation SOP, and the shape of your data stores sits in the data architecture validation SOP.

Use it:

Before the first real customer data goes in, including beta users.
When a B2B prospect sends a security questionnaire and you need honest answers.
After a big structural change, such as adding file uploads, payments or a public API.
When the product was built fast with AI coding tools, since generated code can skip checks like rate limits and access rules.

What do you need before you start?

A Container diagram of your system, ideally from the technical architecture review.
A staging copy of the product with fake data. Never scan or attack production first.
Two test accounts per role (two customers, one admin) so you can test whether one account reaches another's data.
The OWASP references: the OWASP Top 10 for the most common web risks and the OWASP ASVS (Application Security Verification Standard), whose Level 1 is a sensible bar for an early product.
Written permission from your hosting provider's rules if you plan aggressive scans; most allow testing your own resources, some list exceptions.

How do you run it, step by step?

1. Model the threats with STRIDE

STRIDE, created at Microsoft, gives you six questions per component: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Walk each box and arrow on your diagram through the six letters and write down every threat you find.

2. Rank threats by damage to the business

Score each threat for likelihood (1 to 3) and damage (1 to 3). Damage means what a customer or regulator would see: leaked health notes, stolen payouts, a week offline. Keep the top 10 for testing and park the rest in the log.

3. Run the automated scans

Point a ZAP baseline scan at staging, turn on GitHub Dependabot or run npm audit for vulnerable packages, and run Gitleaks across the full Git history for API keys and passwords committed by mistake. Check your HTTP security headers with Mozilla HTTP Observatory. These four scans take an afternoon and cost nothing.

Broken access control sits at the top of the OWASP Top 10, and scanners miss most of it. Log in as Customer A, copy a URL or API request that shows A's data, then replay it as Customer B. Try changing IDs in URLs, calling admin endpoints as a normal user, and resetting a password for someone else's email. Check new passwords against breached lists (Have I Been Pwned's Pwned Passwords service does this without sending the full password), as NIST SP 800-63B recommends.

5. Lock down the accounts that run the company

Turn on multi-factor authentication for hosting, domain registrar, code repository, email, payment processor and the admin panel. Remove former contractors. Attackers go for the founder's inbox before your code.

6. Score, fix and retest

Rate each finding with CVSS (Common Vulnerability Scoring System): 7.0 to 8.9 is high and 9.0 to 10.0 is the top band. Fix everything at 7.0 or above before launch, then rerun the exact test that found it.

7. Write a one-page breach plan

Name who decides, who tells customers and who contacts the regulator. Under GDPR Article 33, a controller notifies the supervisory authority within 72 hours of becoming aware of a personal data breach, so the plan needs names and phone numbers, ready before you need them.

Template you can copy

SECURITY VALIDATION LOG

Part A: Threat model (STRIDE)
Component | Threat (S/T/R/I/D/E) | What an attacker does |
Likelihood 1-3 | Damage 1-3 | Score | Control in place | Tested Y/N

Part B: Scan results
Tool | Date | Findings (high / medium / low) | Fixed | Retested

Part C: Manual access tests
Test | Account used | Expected | Actual | Pass/Fail
1. Customer B opens Customer A's record URL     | B | 403 or 404 |  |
2. Normal user calls /admin endpoint             |   | 403        |  |
3. Password reset for another user's email       |   | No access  |  |
4. 20 wrong passwords in 1 minute                |   | Lockout or slowdown | |
5. Upload a .html or .svg file as an avatar       |   | Rejected   |  |

Part D: Company accounts
Account | MFA on Y/N | Admins listed | Former members removed Y/N

Part E: Breach plan
Decision owner: ___  Customer contact: ___  Regulator contact: ___
Hosting support link: ___   Lawyer or advisor: ___

Worked example: a booking platform for therapists

This is an illustrative case. A two-person team builds scheduling software where therapists keep short session notes. The STRIDE session takes two hours and lists 19 threats; the top 10 go to testing.

The automated scans find 23 issues, mostly missing security headers, and Dependabot flags two packages with high CVSS scores. The manual tests find the real problem: changing the appointment number in the URL shows another therapist's client notes. A scanner never flagged it, because the page loaded normally. On top of that, the hosting account and the domain registrar have no multi-factor authentication, and an ex-freelancer still has admin access to the code repository.

The team spends six developer days on fixes: an ownership check on every record lookup, two package upgrades, security headers, MFA everywhere and the freelancer removed. The retest passes all five access tests.

What should you measure, and when do you stop?

Metric	Pass signal	Warning signal
Open high-severity findings	0 findings at CVSS 7.0 or above	Any open finding at 7.0+ at launch
Threats with a tested control	All top-10 threats have a control that passed a test	Controls exist only on paper
Vulnerable dependencies	No high alerts older than 14 days	Alerts muted or ignored
Access control test pass rate	100% of cross-account tests pass	Any customer reaches another customer's data
Days to patch	High findings fixed within 7 days	No owner for fixes

Stop the first round when every top-10 threat has a passing test and scans come back with no high findings. Repeat the scans monthly and the manual tests after every change to login, roles or file handling. A paid penetration test makes sense once you sign customers whose contracts ask for one.

Which mistakes should you avoid?

Trusting the scanner's green light. Automated tools miss logic flaws like the appointment-ID bug above.
Testing on production. Scans create junk records and can lock accounts. Use staging with fake data.
Leaving secrets in Git history. Deleting a file doesn't remove it from old commits; rotate every secret Gitleaks finds.
Forgetting the company accounts. A hijacked registrar or email inbox bypasses every control in your code.
Writing a security policy nobody tests. Customers and auditors ask for evidence, and a dated test log is evidence.

How can AI speed this up?

Paste your Container diagram and a description of each role into an AI assistant and ask it to draft a STRIDE table; it produces a decent first list in minutes. You can also ask it to read a request handler and point out missing ownership checks, or to turn scan output into plain-language fix tickets.

Check every AI suggestion against the real code, and never paste production secrets, customer data or full private repositories into a public AI tool. AI misses threats that depend on your business, such as a therapist's notes being far more sensitive than their calendar. For short practical lessons on using AI safely in a startup, see the F/MS free AI for startups module.

Where does this SOP fit in your validation plan?

Security validation follows the design work in the Technical Validation SOPs:

Before it: map the system with the technical architecture review SOP.
Alongside it: check third-party connections with integration testing, since webhooks and API keys are common weak spots.
After it: confirm your data stores, backups and deletion rules with data architecture validation.

Founders who want to practise the whole path from idea to launch, security checks included, can play the women-first Fe/male Switch startup game.

FAQ

Do I need a penetration test before launch?

Most early startups don't. Run this SOP first; it catches the common problems for free. Buy a penetration test when a customer contract, an investor or a regulator asks for one.

What is the minimum security a startup needs?

Multi-factor authentication on every company account, no secrets in code, patched dependencies, access checks on every record and a tested backup. That set blocks the attacks small companies face most.

Is OWASP ZAP free?

Yes. ZAP is open source and free, and its baseline scan runs passively against a site you own without attacking it.

How do I answer a customer's security questionnaire as a small startup?

Answer from your validation log: list the controls you have, the date you tested them and what you plan next. Honest "not yet, planned for Q2" answers beat vague yes answers that fall apart in a call.

Security Validation SOP