BoardSnap is an iOS app that reads whiteboard photos and produces clean summaries and action items in about ten seconds. This security review template structures a threat model and security assessment — attack surface, threats, controls, and residual risks — on a whiteboard that BoardSnap documents before a change ships to production.
Use this for any change that touches: authentication, authorization, payment flows, user data storage, external API integrations, file uploads, or public-facing endpoints. Security reviews are not just for new systems — they're for any significant change that expands the attack surface or changes how sensitive data is handled.
Budget 60 minutes for a focused security review. For major new systems, budget 90 minutes. Bring engineering, and at least one person with security context — internal or external.
Write what's being reviewed and what assets this change could put at risk: user PII, payment data, authentication tokens, intellectual property, infrastructure credentials. Naming the assets creates the frame for the threat model — every threat is relevant only insofar as it threatens an asset.
Write every point where the system accepts input from an untrusted source: HTTP endpoints, file upload handlers, OAuth callbacks, webhooks, mobile app inputs, third-party API responses. The attack surface is not the same as the feature surface — it's the set of points an attacker could manipulate.
For each attack surface point: what threats apply? Use STRIDE as a structure if useful: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Write the threats that are relevant to each attack surface point. Don't try to enumerate every possible threat — focus on the plausible ones for your threat model.
For each threat: what controls are in place? Authentication, input validation, rate limiting, encryption at rest, encryption in transit, audit logging, access control. For each control: is it implemented, partially implemented, or absent? Mark each honestly.
Write the threats that aren't fully controlled — either because controls are absent, partially implemented, or accepted by design. For each residual risk: severity, likelihood, and disposition (mitigate, accept, transfer). For risks being mitigated: write the action items, owner, and date.
Write what you're protecting first. A threat model without named assets produces a list of generic threats. A threat model with named assets produces a prioritized threat list — because threats that don't endanger a named asset are not relevant to this review.
Trace every input boundary. For web applications: every HTTP endpoint. For mobile: every network call, file system access, and deep link handler. For backend services: every queue consumer, webhook receiver, and cron job. Write them all on the board before moving to threats.
For each attack surface point: go through STRIDE. 'Can this endpoint be used to Spoof identity? Can the request be Tampered with? Is the action Repudiable? Could this Disclose information? Could it be used for Denial of Service? Could it allow Elevation of Privilege?' Not every letter applies to every point — use it as a prompt, not a mandatory checklist.
For each threat: write what control exists. If the answer is 'nothing,' write that. A security review that inflates control coverage produces false confidence — which is worse than no security review at all.
For each residual risk: is this being mitigated (action item assigned), accepted (risk owner named), or transferred (insurance, third-party)? 'We'll deal with it later' is acceptance without documentation — make it explicit so the acceptance is a decision, not an oversight.
BoardSnap reads the assets, attack surface, threats, controls, and residual risks. The output is a structured security review record — residual risks and mitigation actions are the action items, and the scope and decisions are documented before the change ships.
Security reviews written in a document after a change ships are post-hoc documentation, not actual security practice. A security review run on a whiteboard before a change ships — with the attack surface drawn out and the threats named in front of the engineering team — changes the decisions that get made about how to build the feature.
BoardSnap makes the security review a first-class artifact. The review is documented, dated, and linked to the change it covers. When an audit or an incident asks 'did you review the security of this?' the answer is in BoardSnap.
Threat modeling is a structured process for identifying, quantifying, and addressing security threats to a system. The most common approach is STRIDE — developed at Microsoft — which prompts analysis of six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Threat modeling is done before implementation, not after.
Ideally yes, but not necessarily. A senior engineer with security training can run this template effectively. The important thing is that the review is structured — unstructured security discussions produce inconsistent coverage. If you have no internal security expertise, consider having an external security consultant review high-risk changes.
A security review is a design-time activity — it evaluates the security of a system before or as it's being built. A penetration test is a runtime activity — it tests the security of a running system by attempting to exploit it. Security reviews are cheaper and catch design flaws early; pen tests confirm whether implementation is secure. Both are necessary for high-assurance systems.
The free tier includes one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat on every board you snap.
No exporting, no transcription. Snap the board, get the action plan.