Security baseline self-assessment: the 25 MVSP controls
The first large customer sends a security questionnaire and asks for an audit report you don't have. What you can send is a dated, honest self-assessment against a public baseline. The Minimum Viable Secure Product list was written by Google, Salesforce, Okta and others to be short enough for a small company to meet. Answer each of its 25 controls, add a note, and print or copy the result.
Your answers are saved in this browser only. Nothing is sent to us.
1 Business controls
A page that says how to report a security problem, what may be tested and that you won't sue a good-faith reporter, plus a security.txt file pointing to it. An afternoon's work.
MVSP wording
- Publish a vulnerability disclosure policy that outlines the testing scope, provides a legal safe harbor, and gives contact details for security reports
- Develop and document procedures for triaging and remediating reported vulnerabilities
- Respond to reports within a reasonable time frame
- Patch vulnerabilities consistent with Control 3.4
Say yes when a customer asks to test you, with a few rules (notice, no load tests, their own account). A staging copy must not hold real customer data.
MVSP wording
- On request, enable your customers or their delegates to test the security of your application
- Test on a production or a non-production environment that closely resembles the production environment in functionality
- Ensure non-production environments do not contain production data
- Reasonable restrictions on testing can be defined
This page. Fill it in honestly, date it, attach it to questionnaires and do it again within a year.
MVSP wording
- Perform and make available security self-assessments for each qualifying product/service, using the latest MVSP release, at least annually
A paid penetration test once a year. Often the most expensive line here; a small vendor can book a first test once the first large customer is near.
MVSP wording
- Contract a security vendor to perform comprehensive penetration tests of your products, services, and dependent systems, at least annually
Developers learn the common flaws (see 3.3), whoever handles support learns not to reset accounts on a phone call. A walk-through with a signed sheet counts as a start.
MVSP wording
- Implement role-specific security training for your personnel that is relevant to their business function
Know which rules apply (GDPR if you hold data on people in Europe, PCI DSS if card numbers touch your servers) and be able to say how you meet them. Not holding an audit report is not the same as not complying.
MVSP wording
- Comply with industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18
- Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses
- Ensure data localization requirements are implemented in line with local regulations and contractual obligations
A one-page plan: who decides it is a breach, who tells customers within 72 hours, and a ready message with the four parts MVSP lists.
MVSP wording
- Notify relevant parties about any security breach that affects sensitive information no later than 72 hours upon discovery, and upon learning any additional details of the breach
- Consider reporting the breach to relevant national cybersecurity agencies in line with local guidance and regulations
- Include the following information in the notification: Nature of the breach; Relevant contact information; Consequences of the breach; Measures taken, or needing to be taken, to remediate the issue
Disks with customer data are wiped properly before they leave. If everything runs at a cloud provider, their process covers the servers; your own laptops with production data are yours.
MVSP wording
- Ensure media sanitization processes based on NIST SP 800-88 (or equivalent) are implemented for storage media holding unencrypted production data
Often not applicable to a cloud-only product with encrypted staff laptops; say why in the note.
2 Application design controls
Customers can sign in with their company's Google, Microsoft or Okta account (OIDC or SAML), and you don't charge extra for it.
MVSP wording
- Implement single sign-on using modern, maintained, and industry-standard protocols for all customers at no additional cost
Plain HTTP redirects to HTTPS, a free TLS scan comes back clean, the Strict-Transport-Security header is set and sign-in cookies are marked Secure.
MVSP wording
- Redirect traffic from HTTP protocol (port 80) to HTTPS (port 443)
- This does not apply to secure protocols designed to run on top of unencrypted connections, such as OCSP
- Scan and address issues using freely available modern TLS scanning tools
- Include the Strict-Transport-Security header with a long max-age value
- Set authentication cookies as Secure
A Content Security Policy, a header that stops other sites framing your app, and no caching of pages or API answers with customer data.
MVSP wording
- Apply appropriate security headers to reduce the application attack surface and limit post exploitation:
- Set a minimally permissive Content Security Policy
- Limit the ability to iframe the application by enabling framing controls with X-Frame-Options or CSP frame-ancestors
- Disable caching for APIs and endpoints that return sensitive data
Long passwords allowed, stored with bcrypt, scrypt or Argon2, resets by email only, the old password asked before a change, sign-in attempts limited, no default passwords.
MVSP wording
- If password authentication is used in addition to single sign-on:
- Do not limit the permitted characters that can be used
- Do not limit the length of the password to anything below 64 characters
- Do not use secret questions as a sole password reset requirement
- Require email verification of a password change request
- Require the current password in addition to the new password during password change
- Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function
- Enforce appropriate account lockout and brute-force protection on account access
- Do not provide default passwords for users or administrators
Not applicable if there are no passwords at all (sign-in only by SSO or emailed codes).
Build on a maintained framework that escapes output and parameterises queries for you (an ORM, React or a template engine), rather than hand-built SQL strings and HTML.
MVSP wording
- Use modern, maintained, and industry-standard frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs
Turn on Dependabot or a similar alert, apply medium and higher fixes on a schedule, and drop everything for anything on the CISA known-exploited list.
MVSP wording
- Ensure third-party dependencies are maintained and up-to-date, with security relevant updates having a severity score of "medium" or higher applied in line with your application patching schedule
- Upon becoming aware of a Known Exploited Vulnerability affecting a third-party dependency, the patch should be prioritized
- Where dependency patching or upgrades are not possible, equivalent mitigations should be implemented for all components of the application stack
Record sign-ins, changes to users and records, settings changes and your own staff looking at customer data, with who, from where, when and what. Keep 30 days at least, without passwords or payloads.
MVSP wording
- Keep logs of: Authentication events (success and failure); Create, Read, Update, and Delete (CRUD) operations on application and system users and objects; Security relevant configuration changes (including disabling logging); Application owner access to customer data (access transparency)
- Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action. Logs must be stored for at least 30 days at no additional charge, and should not contain sensitive data or payloads.
HTTPS between systems as well as to the browser, and encrypted disks, databases and backups. Most cloud databases do the at-rest part if it is switched on.
MVSP wording
- Use modern, maintained, and industry-standard means of encryption to protect sensitive data in transit between systems, and at rest in online data storages and backups
3 Application implementation controls
A short list: what personal or sensitive data the product holds (names, emails, files, payment references) and why. An hour, and it answers half a questionnaire.
MVSP wording
- Maintain a list of sensitive data types that the application is expected to process
One drawing: browser to app to database, backups, email provider, AI model provider, analytics. Every box where customer data lands.
MVSP wording
- Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored
A one-page guideline that names these six, checked in code review. Authorization bypass is the one most often found in small products: every query filtered by the customer it belongs to.
MVSP wording
- Train your developers and implement development guidelines to prevent at least the following vulnerabilities:
- Authorization bypass (accessing other customers' data or admin features from a regular account)
- Insecure session management (guessable token; a token stored in an insecure location)
- Injections ((No)SQL injection, LLM / Prompt injection, XXE, OS command injection)
- Cross-site scripting
- Cross-site request forgery
- Handling untrusted data (reusing data supplied by users within sensitive application contexts)
Promise 90 days at most for a serious flaw, faster when it is being exploited, and a public note when customers need to act.
MVSP wording
- Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery
- For vulnerabilities with evidence of active exploitation, production and deployment of patches should be prioritized
- Publish a security bulletin that details the vulnerability and its root cause if the remedy requires action from customers
Code in git, built the same way every time by a script or CI that records what was built from which commit, and no keys in the repository.
MVSP wording
- Must use a version control system and consistent build process that generates provenance describing how the artifact was built (SLSA Build Level 1)
- Sensitive application credentials and tokens should be stored separately from the application's source code
4 Operational controls
For a cloud-hosted product, the data centre is your provider's: point to their audit report. Your own office matters only if production data or servers are there.
MVSP wording
- Validate the physical security of relevant facilities by ensuring the following controls are in place:
- Layered perimeter controls and interior barriers
- Managed access to keys
- Entry and exit logs
- Appropriate response plan for unauthorized access
Fair when you own no facility holding production data; name the provider in the note.
Only the people who need production have it, leavers are removed the same day, someone looks at the list every quarter, and two-step sign-in is on everywhere production can be reached.
MVSP wording
- Limit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such access
- Deactivate redundant accounts and expired access grants in a timely manner
- Perform regular reviews of access to validate need to know
- Ensure remote access to customer data or production systems requires the use of Multi-Factor Authentication
A list of every company that touches customer data (hosting, email, AI model, support desk, analytics), with what each gets. Large customers ask for it first.
MVSP wording
- Maintain a list of third-party companies with access to customer data, and make it available to clients and business partners upon request
- Assess third-party companies annually against the latest MVSP release
Encrypted backups somewhere else (another region or provider), and a restore actually done and timed at least once a year.
MVSP wording
- Securely backup all data to a different location than where the application is running
- Maintain and test disaster recovery plans in concert with your incident response planning, at least annually or after significant changes
Security baseline self-assessment
Against the Minimum Viable Secure Product controls (mvsp.dev) · Met 0 · Partly 0 · Not yet 0 · Not applicable 0 · Not answered 25
| Control | Answer | Note | Date |
|---|---|---|---|
| 1 Business controls · met 0/8 | |||
| 1.1 External vulnerability reports | Not answered | ||
| 1.2 Customer testing | Not answered | ||
| 1.3 Self-assessment | Not answered | ||
| 1.4 External testing | Not answered | ||
| 1.5 Training | Not answered | ||
| 1.6 Compliance | Not answered | ||
| 1.7 Incident handling | Not answered | ||
| 1.8 Data handling | Not answered | ||
| 2 Application design controls · met 0/8 | |||
| 2.1 Single Sign-On | Not answered | ||
| 2.2 HTTPS-only | Not answered | ||
| 2.3 Security Headers | Not answered | ||
| 2.4 Password policy | Not answered | ||
| 2.5 Security libraries | Not answered | ||
| 2.6 Dependency Patching | Not answered | ||
| 2.7 Logging | Not answered | ||
| 2.8 Encryption | Not answered | ||
| 3 Application implementation controls · met 0/5 | |||
| 3.1 List of data | Not answered | ||
| 3.2 Data flow diagram | Not answered | ||
| 3.3 Vulnerability prevention | Not answered | ||
| 3.4 Time to fix vulnerabilities | Not answered | ||
| 3.5 Build and release process | Not answered | ||
| 4 Operational controls · met 0/4 | |||
| 4.1 Physical access | Not answered | ||
| 4.2 Logical access | Not answered | ||
| 4.3 Sub-processors | Not answered | ||
| 4.4 Backup and Disaster recovery | Not answered | ||
A self-assessment, not an audit report. biz59.net/tools/security-baseline
Where this list comes from
The 25 controls and their wording are the Minimum Viable Secure Product list, published at mvsp.dev under a CC0 public-domain licence and read on 15 October 2026. Control 1.3 asks for exactly this: a self-assessment against the latest release, at least once a year. The plain-language lines, the work order and the suggested wording are ours.
How to answer the questionnaire itself, row by row, is in our article the security questionnaire arrives: what a five-person software vendor can honestly answer. If the product was built quickly with AI tools, run the launch checklist as well.
A self-assessment, not an audit and not legal advice. More free tools: biz59.net/tools.