MVSP, the Minimum Viable Secure Product, is a list of essential application security controls that enterprise-ready products and services should have, with Google, Salesforce, Okta and Slack among the contributors its site lists. Buyers can put it in procurement and contracts. For one small SaaS, meeting it means a table: each control, who owns it, and the evidence behind it.
What MVSP is, and what a controls checklist with evidence looks like
A controls checklist with evidence is a table with one row per control that applies to the app: the control in plain words, the person who owns it, and a link to the artifact that proves it. MVSP supplies the rows, 25 controls in 4 sections; a row ending in a sentence instead of an artifact is unfinished.
That table is one part of how to manage SaaS data compliance, and it is the part a buyer’s reviewer reads line by line.
MVSP’s home page calls it “A minimum security baseline for enterprise-ready products and services” and recommends that “all companies building enterprise software and services, or otherwise handling sensitive information” put its controls in place and, where they can, go well beyond them. It names four places to use the list: procurement, where it is meant to be short enough to include in RFP documents; self-assessment, for smaller companies “not yet mature enough to invest in large compliance efforts such as SOC 2 or PCI DSS”; the software development lifecycle; and contractual controls, where large companies can write it into their standard supplier terms. The contributors it lists include Google, Salesforce, Okta, Slack, Netflix and CISA, and the list is public domain under a CC0 license, so copying its rows into your own table is fine.
The MVSP checklist splits its 25 controls into four sections: business controls, application design controls, application implementation controls and operational controls. The page prints no version number of its own. It links earlier releases, the newest labeled v2.0-20221012, and its control titles have changed since that release, so record the date you read it.
Below is my mapping for a small SaaS run by two people: a founder who runs the business and a tech lead who runs the code. The id and title in the first column are MVSP’s; the meaning, owner and evidence columns are my reading, and in your copy each owner cell holds a person’s name.
| MVSP control | What it means for one small SaaS | Owner | Evidence a stranger can check |
|---|---|---|---|
| 1.1 External vulnerability reports | A published disclosure policy with a contact, a testing scope and a safe harbor, plus a way to triage what arrives | Tech lead | The live policy URL and the triage note for the last report |
| 1.2 Customer testing | A customer or their delegate may test the app on request, and no production data sits in test environments | Tech lead | The written testing terms and the staging seed script |
| 1.3 Self-assessment | This table, filled against the latest MVSP release at least once a year | Founder | The dated table and last year’s copy |
| 1.4 External testing | A penetration test by a security vendor, at least once a year | Founder | The vendor’s dated report, or a row saying none yet and when |
| 1.5 Training | Security training that fits each person’s role | Founder | A dated completion record per person |
| 1.6 Compliance | The industry standards and local laws that apply to the business | Founder | A one-page list of which apply and the document behind each |
| 1.7 Incident handling | Relevant parties told about a breach of sensitive information no later than 72 hours after discovery | Tech lead | The incident plan’s notification step and the record of the last drill |
| 1.8 Data handling | Storage holding unencrypted production data is wiped to NIST SP 800-88 or an equivalent | Tech lead | Not applicable to the host’s disks on a hosted stack; a dated wipe record for any laptop that held an export |
| 2.1 Single Sign-On | Single sign-on on a standard protocol for every customer, at no extra cost | Tech lead | A test login through a customer’s identity provider and the pricing page with no surcharge |
| 2.2 HTTPS-only | HTTP redirects to HTTPS, a Strict-Transport-Security header with a long max-age, Secure auth cookies | Tech lead | A saved production response showing the redirect, the header and the cookie flags |
| 2.3 Security Headers | A tight Content Security Policy, framing controls, and no caching on endpoints that return sensitive data | Tech lead | The response headers saved from production |
| 2.4 Password policy | If passwords exist next to single sign-on: no length cap below 64 characters, salted hashes, appropriate lockout and brute-force protection | Tech lead | The auth settings export and a test record of the lockout |
| 2.5 Security libraries | Frameworks that escape output and sanitize input, such as an ORM and a UI framework | Tech lead | The dependency list and a search for raw SQL or raw HTML, each hit explained |
| 2.6 Dependency Patching | Security updates rated medium or higher applied on your patching schedule | Tech lead | The dependency scan report and the merged update pull requests |
| 2.7 Logging | Logs of sign-in successes and failures, every create, read, update and delete on users and records, security setting changes and your own access to customer data, kept at least 30 days at no extra charge | Tech lead | One sample log line with user, IP, time, action and object, and the retention setting |
| 2.8 Encryption | Sensitive data encrypted in transit and at rest, backups included | Tech lead | The host’s encryption setting and a database read showing how a secret column is stored |
| 3.1 List of data | A list of the sensitive data types the app processes | Founder | The dated data list |
| 3.2 Data flow diagram | A current diagram of how sensitive data arrives and where it ends up stored | Tech lead | The diagram, dated after the last schema change |
| 3.3 Vulnerability prevention | Written guidelines and developer training against authorization bypass, session flaws, injection, cross-site scripting, request forgery and untrusted data | Tech lead | The guidelines and a test record per class, starting with one account trying to read another’s data |
| 3.4 Time to fix vulnerabilities | Fixes for vulnerabilities that materially affect security shipped within 90 days of discovery | Tech lead | The issue list with found and fixed dates |
| 3.5 Build and release process | Version control, a consistent build that records how each artifact was built, credentials kept out of source | Tech lead | The build log with its provenance record and a secret scan of the repository |
| 4.1 Physical access | Physical security of the facilities that matter | Founder | Not applicable on a hosted stack with no servers of your own; the host’s own report is the evidence |
| 4.2 Logical access | Sensitive data reachable only by people who need it, stale accounts removed, access reviewed, multi-factor on remote access to customer data or production | Founder | The dated access review and an export of admin users with the second factor on |
| 4.3 Sub-processors | A list of third parties with access to customer data, shared on request and checked yearly | Founder | The published subprocessor list and the yearly check notes |
| 4.4 Backup and Disaster recovery | Backups stored away from where the app runs, and a recovery plan tested at least once a year or after significant changes | Tech lead | The dated restore log with the row count checked |
An enterprise security review checklist is only as good as its evidence column, so collect evidence for each security control as you write its row. The way to pass a security review is to have a row, an owner and a link ready for every question the buyer asks. Filled in before a release instead of after the buyer’s email, the same table doubles as a pre-release audit checklist.
A controls checklist is not a security audit or certification for enterprise sales: it is your own record, and nobody outside signs it. When a buyer asks which SaaS security certifications you hold, they usually mean a SOC 2 report or an ISO 27001 certificate; MVSP is a self-assessment and issues no certificate. If a contract names SOC 2, start with do I need SOC 2 and the difference in SOC 2 Type 1 vs Type 2. If it names ISO 27001 instead, the auditor’s evidence list and what ISO 27001 certification costs a small SaaS are a separate decision from this table.
In the Production Hardening Sprint, deliverable 12.6, the SOC 2-style controls checklist, is a technical controls checklist with supporting evidence organized for enterprise security review, because enterprise buyers need evidence of how the application is protected and operated.
Controls examples: what a control is, its purpose, the control owner and the evidence
A security control is one specific, repeatable thing the app or the team does to reduce one risk, written as the risk, the mechanism and how often it runs. The control owner is whoever can prove it works; the evidence is an artifact a stranger can check, such as a config export, a test record or a restore log.
NIST’s glossary defines a security control as “A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.” For a small app I work with four plainer definitions. A control description names the risk, the mechanism and the frequency. The purpose of a control is to reduce one named risk; when a control claims to reduce three, I split it into three rows. The control owner is the person who can prove it works, which is not always the person who built it. Evidence of compliance is the artifact itself, and proof of compliance carries the same meaning: a file, a log or a test result, never a statement that the thing is done.
Each row below is an example of a control from one app, written with those four parts. They illustrate the method; they are not findings, and they name no vendor setting.
| Control description | Purpose | Owner | Evidence |
|---|---|---|---|
| The login route accepts a limited number of attempts per account and per IP address in a time window, on every request | Slow down password guessing | Tech lead | The config line, and a test record showing the route refusing requests once they went past the limit (not necessarily on the first one over, since some limiters let a few extra through before their counters catch up) |
| Database backups are restored into a scratch database on a schedule and checked | Make sure a working copy of the data exists before it is needed | Tech lead | The dated restore log and the row count checked against production |
| Every admin account signs in with a second factor | Stop one stolen password from opening the most powerful accounts | Founder | An export of admin users with the second factor on for each |
I audited a healthcare community app whose schema comment and public security page promised AES-256 encryption at rest for users’ bot tokens and OAuth tokens, while the write path stored them as plain JSON. A leaked database URL or backup would hand over working credentials, and the written promise was false. The lesson I take from it: a sentence on a security page is a policy, and only the stored row is evidence. How a policy and a control differ when nobody on the team does security full time is covered in SOC 2 with no security team.
What goes wrong without it: the customer security review process with no evidence
A security review, seen from the supplier’s side, is the buyer reading your answers and asking for the artifact behind any one of them. That differs from a security review of your own app, which tests the code and settings themselves; the buyer only sees what you can prove about them. Without a controls table, the failures look like this.
| Symptom | Likely cause | First check |
|---|---|---|
| The questionnaire arrives and the honest answers would be guesses | No controls table exists | Start the table from MVSP’s rows and fill the owner column first |
| A policy promises something the app does not do | The policy was written from a template, not from the app | Compare each policy sentence with a control row and its artifact |
| The buyer asks for a report you do not have | The team assumed SOC 2 was the only route | Answer with the table and say plainly what exists today |
The moment that first row describes is the subject of a big customer sent a security questionnaire, and the questions themselves are easier to answer after reading some security questionnaire examples. The second row is the token case above in another form. The third row’s SOC 2 question stays with the two SOC 2 pages in the first section.
The customer security review process itself is short to describe: the buyer’s team reads your table and your policies against each other, and asks for links wherever the two disagree or a row has no artifact.
Security policies a review asks to see, and the shortest version that is true
A security policy is a written rule for how a company protects its data and systems. For a two-person SaaS my working set is short: about seven one-page documents covering access control, acceptable use, incident response, data classification and retention, vendor management, secure development and continuity, each stating what is true now, its owner and its control rows.
The set below is my working set, not a standard’s list. The MVSP ids come from the checklist; which policy points at which row is my mapping.
| Policy | What it must say for a two-person team | MVSP rows |
|---|---|---|
| Access control | Who can reach production and customer data, that admin accounts use a second factor, and when access is next reviewed | 2.1, 2.4, 4.2 |
| Acceptable use | What company accounts and laptops are for, and that customer data never goes to personal devices or unapproved tools | 1.5 |
| Incident response | Who is called first, how a breach is assessed, and who tells customers within the deadline (MVSP’s row says no later than 72 hours) | 1.7 |
| Data classification and retention | Which data types count as sensitive, where each one lives, and how long each is kept | 1.8, 3.1 |
| Vendor management | Which third parties touch customer data, why, and when each was last checked | 4.3 |
| Secure development | How code is reviewed, how dependencies are patched, how fast security fixes ship, and where secrets are kept | 2.5, 2.6, 3.3, 3.4, 3.5 |
| Business continuity | Where backups live, how often a restore is tested, and who runs the recovery | 4.4 |
Information security policy examples written for a large company assign duties to roles a two-person team does not have, so keep their headings and rewrite every sentence. One policy doc per topic, one page each, dated at the top, is easier to keep true than one long handbook nobody rereads. An organization security policy for a two-person company is this same set, with both founders’ names on it. When a buyer asks for a cyber security plan, I’d send the same set; that is my reading of what the request wants. Security policy management, at this size, means a review date on every page and a named owner who rereads it on that date. If you want examples of security policies to compare against, the table above is the shortest set I would put in front of a reviewer.
Each policy has a neighbor topic with more depth. Retention detail belongs with what a data retention policy is. The vendor policy rests on knowing what a sub-processor is. The incident policy is one page; the plan behind it starts from an incident response plan template. The classification row is quicker with a data map GDPR reviewers accept already drawn.
These are the documents a security review asks to see, not what any law requires, and nothing here is legal advice. The SOC 2 version of the same split, what somebody writes down against what the app has to do, and the evidence a SOC 2 auditor asks for, are in that same SOC 2 with no security team article; this set is mapped to MVSP for a buyer’s review, not to a SOC 2 audit.
IT security policy templates: what they give you and where they fail a small team
An IT security policy template gives you structure, not content: headings, a purpose line and a place for an owner, but none of the facts about your app. SANS and the Cybersecurity Risk Foundation publish a free library of 36 information security policy templates, from an Access Management Policy to a Third-Party Management Policy. The library is a directory, and the page does not say which of the 36 a small SaaS needs.
The common failure across IT security policy templates is the committee. FRSecure’s template, for one, has the company designate an Information Security Officer and has that officer chair an Information Security Committee. A SaaS security policy template that describes a committee your company does not have fails the review, because the reviewer can ask to meet it. A data security policy template is safer when each heading is filled from your own data list (MVSP 3.1) instead of from its sample text. Even an information security policy template for small business is only as good as the sentences you put in it.
So take the headings from a template and the sentences from the policy table above, with every sentence true today and pointing at a control row.
What “enterprise ready” means on a feature list
Enterprise ready on a feature list is a set of controls, not a badge. EnterpriseReady’s list includes single sign-on, audit logs and role-based access control, and a buyer’s security review may add data lines such as a signed DPA and a subprocessor list. Each feature is a control with an owner and evidence.
EnterpriseReady names 12 feature categories, drawn from “a study of the 50 leading SaaS applications”. The security features enterprise customers ask for are, in my reading, the first three rows below plus the data lines, and each maps to a row MVSP already lists, which is the point of a baseline written for enterprise-ready products. The control column is my reading; the MVSP ids are the checklist’s.
| Feature buyers ask for | The control behind it | MVSP row |
|---|---|---|
| Single sign-on | Customers manage their own users from their own directory, at no extra cost | 2.1 |
| Audit logs | A trail of who did what to which record, kept at least 30 days | 2.7 |
| Role-based access control | Each user sees and changes only what their role allows | 4.2 |
| Data export and deletion | A customer can take its data out and have it deleted, including from storage you control | 1.8 |
| A signed DPA | A contract saying what you do with the customer’s personal data and under which law | 1.6 |
| A subprocessor list | A published list of the third parties that can reach customer data | 4.3 |
The first three are on EnterpriseReady’s list. A DPA and a subprocessor list are not among its 12 categories, which include GDPR as a category of its own, and data export sits closest to its Integrations guide, which talks about letting customers “pull data out”. Those last three rows are my additions from what a buyer’s security review asks.
Single sign-on in depth belongs with an authentication checklist. The DPA is its own document: what is a DPA agreement, and what Article 28 puts in it. For what each line on a buyer’s list means and where it goes, the audit-log line included, read your first enterprise customer’s requirements list.
One line applies only if your app asks Google users for restricted data. Per Google’s restricted scope verification page, every app that requests access to Google users’ restricted data and has the ability to access data from or through a third-party server must go through a security assessment, and, to keep access to any verified restricted scopes, must complete one again at least every 12 months after the assessor’s Letter of Assessment approval date. Google uses the App Defense Alliance’s cloud application security assessment framework, CASA, for that assessment. The App Defense Alliance’s CASA framework is built on OWASP’s Application Security Verification Standard (ASVS), is carried out by ADA authorized labs at assurance levels AL1 and AL2, and on who picks the level it says: “The framework users (Google..etc) and not the application developer calculate and determine which assurance level is required.” Levels, assessors and costs are a topic of their own: cloud application security assessment in full.
How to set it up
Six steps, each leaving something behind that a reviewer can open.
- 01 Open the current MVSP checklist on mvsp.dev and write down the date you read it and the earlier releases it lists, since the page shows no version number of its own. Evidence: a dated copy in your evidence folder.
- 02 Strike the rows that do not apply and write the reason beside each one. Evidence: the reason, in the row, in a sentence a stranger understands.
- 03 Put one named owner on every remaining row. Evidence: a name in the owner cell, not a job title.
- 04 Attach one evidence artifact per row: a link, an export or a test record, never a sentence. Evidence: the link opens for someone outside the company.
- 05 Write the one-page policies from the policies table and link each one to its control rows. Evidence: every policy lists the MVSP ids it points at.
- 06 Date the table and keep it with the due diligence pack you send buyers. Evidence: the date at the top and the same copy in the pack.
How to verify it
A controls checklist is verified by following links, not by reading it. My working rule is to pick five rows at random and follow each one to its artifact: a configuration, a test record, a log or a report a stranger could check. Any row that ends in a sentence instead of an artifact goes back on the list.
Five rows is roughly a fifth of the table, enough for a first pass; I’d pick more if a buyer is waiting on it. Each check below can fail, and each leaves a record.
- 01 Pick five rows at random and follow each link. Pass: each one opens an artifact a stranger could check. Fail: a dead link, a login the reviewer will not have, or a sentence.
- 02 For each policy, find the control row it points at and check that the row's artifact says the same thing as the policy. Fail: the policy promises what the stored data does not show, as in the token case above.
- 03 For each row marked not applicable, check that the reason still holds this month. Fail: the reason names a host, an office or a feature that has changed.
- 04 Check that every row has one named owner who is still on the team. Fail: a blank, a job title with no name, or someone who has left.
In the sprint, deliverable 12.6 is verified this way: link each documented control to its owner, configuration, or test evidence. This deliverable is not a SOC 2 audit report.
What a SOC 2 report is, and who may issue one, is a separate subject: SOC 2 certification, in plain words.
Where the sprint does this
In the Production Hardening Sprint, the handover includes a readiness report and technical due diligence pack: the readiness report, architecture diagram, data model, security checklist, and capacity statement in one PDF (13.6). Deliverable 13.1, the production readiness report, is verified this way: account for all 123 IDs; keep failures visible until resolved and explain genuine non-applicable items. A control that does not apply to the product is marked with a written reason. Legal advice and certification are separate services; we implement and document the technical data-handling controls. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. Every item is listed in the published scope of the sprint.
Common questions about security controls and policies
What are the 5 key elements of a security policy?
My working five are the purpose, the scope, the rule itself, the owner, and the evidence with a review date. That is my list, not a standard’s, and the last element is the one a reviewer tests, because it points at something they can open.
Can you give me an example of a security policy for an organization?
Yes: here is a one-page access control policy for a two-person company, in four sentences. “Customers can sign in through single sign-on, and only the two founders hold admin access to production and the database, each with a second factor. Customer data is reached through the app’s admin screen, never copied out to a laptop. Access is reviewed on the first working day of each quarter and the review is saved in the evidence folder. The tech lead owns this policy.” It points at MVSP 2.1, Single Sign-On, and 4.2, Logical access.
How to write an information security policy?
Start from the control rows, not a blank page: write only what is true today, name one owner, date it, and link each sentence to the row that proves it. A sentence you cannot link is either a control you still need to build or a sentence to delete.
What are the four types of controls?
The four types in common use are preventive, detective, corrective and compensating controls. In one app: a login rate limit prevents, an alert on a spike in failed sign-ins detects, a tested restore from backup corrects, and a second factor on every admin account while single sign-on is not built yet compensates. The grouping is common usage, not a standard’s list; NIST’s glossary does define a compensating security control, as one “employed by an organization in lieu of a recommended security control” that “provides equivalent or comparable protection”.
What is a security process review?
A security process review is the buyer’s check, during a vendor review, that what your policies promise matches what your controls table can prove, with a request for the artifact behind any line they doubt. That is my reading of the term in a sales context, not a formal definition; the practical test is whether every policy sentence has a row and every row has a link.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase