Security Vendors With Strong Practices and No Documentation

Here is a contradiction I run into constantly.

A security software vendor calls for a SOC 2 readiness conversation. We start poking at their environment. MFA is everywhere. Encryption is the default, in transit and at rest. Endpoints are managed. Logs are centralized. Someone is paged when something looks wrong. By any reasonable measure, the security is real, and in several places, it is better than what I see at companies that have already passed audit.

What is missing is the paperwork. There is no written information security policy. No documented access control procedure. No change management workflow that exists outside the engineers' heads. The team knows how things work because they built it, and that institutional knowledge was enough until a customer or auditor asked for proof.

Why security vendors specifically run into this

The pattern is structural. Security vendors tend to be founded by deeply technical people. The early team is engineers. The product itself is built with security as a core property, not an afterthought. When the founders need MFA, they turn it on across every system the same week. When they need encryption, they architect it in from day one. When they need monitoring, they configure their own SIEM rather than buying a managed service.

In that environment, documentation feels redundant. Everyone already knows how access is granted because three of them granted it. Everyone knows the patching cadence because the same engineer runs it every Tuesday. Writing a policy that says we use MFA feels like an insult to the people who built the system that enforces MFA.

It works fine until the company starts selling to enterprise, regulated industries, or government. Then the questions change.

Where the gap surfaces first

Not through an internal review. Through someone outside asking a question the team cannot answer in writing.

• Enterprise security questionnaires. A prospect sends a 200-question vendor assessment. Most ask whether you have a documented policy for X. The honest answer is we do X every day, which is not the same answer.
• Vendor risk assessments. A larger customer's third-party risk team asks for the information security policy, the incident response plan, the access review procedure. The vendor sends a hastily written one-pager and the deal stalls.
• RFP responses. Government and regulated buyers require evidence of formal program elements at the proposal stage. Without documents to attach, the bid is non-responsive.
• Customer-driven audits. A strategic account exercises the audit clause and walks through the program. Strong technical demos do not compensate for missing written procedures.
• Certification body intake. The first conversation with a SOC 2 auditor or ISO 27001 registrar surfaces the gap immediately. The auditor asks for the document inventory before scoping the engagement.

By the time any of these conversations happen, the deal or the timeline is already at risk. Documentation is not the kind of work that can be done in the week before a customer meeting.

What compliance documentation actually means

There is a misconception that compliance documentation requires fifty-page policy binders, formal change control boards, and quarterly committee minutes. For a security vendor going through SOC 2 or ISO 27001 for the first time, that is the wrong mental model.

Useful documentation answers four questions for every control area: who does this work, what exactly do they do, when, and what evidence proves it happened. A two-page access control policy that names the system owner, defines the request and approval flow, sets a quarterly review cadence, and points to the identity provider as the system of record is more useful than a thirty-page template downloaded from a vendor blog.

The auditor is not grading prose. The auditor is checking whether the document accurately describes the operating reality and whether the operating reality produces the evidence the document claims it does. Short, accurate, and operational beats long, generic, and aspirational every time.

The five documents most security vendors are missing

Across engagements with security ISVs, encryption companies, authentication providers, MSSPs, and defence-adjacent IT firms, the same five documents tend to be missing or insufficient:

1. Information security policy. The top-level document naming the security objectives, assigning overall ownership, and listing supporting policies. Often missing because the founders consider it self-evident.
2. Access control policy. How identities are provisioned, modified, and removed across systems, who approves access, how it is reviewed. The technology is usually solid; the written procedure is usually absent.
3. Change management process. How code and infrastructure changes are proposed, reviewed, tested, and deployed. Most teams already do this through pull requests and CI/CD. The gap is writing down the steps already enforced by the tooling.
4. Incident response plan. The on-call structure, severity definitions, communication tree, post-incident review cadence. Many vendors handle incidents well in practice but have no written plan to show during a procurement review.
5. Vendor risk policy. How third-party services are evaluated before adoption and reviewed on an ongoing basis. This is frequently a net-new addition, since informal vendor selection rarely produces an audit trail.

These five cover a disproportionate share of SOC 2 Common Criteria and ISO 27001 Annex A controls. Getting them written, even in short form, closes most of the visible gap.

What you genuinely need to add, not just document

Documentation closes most of the gap. Not all of it. A handful of program elements tend to be missing as practices, not just as paperwork: a structured annual risk assessment, security awareness training records for every employee including founders, a vendor review cycle that produces an artifact, access reviews on a defined cadence with signed records, and internal audit or control monitoring (ISO 27001 requires it explicitly; SOC 2 expects ongoing monitoring).

Even with these additions, the total effort tends to be smaller than the documentation lift, and most of it can be operationalized as recurring procedures once the GRC platform is set up.

Evidence already exists

For a security vendor, evidence is not something that needs to be created. It is something that needs to be located and catalogued.

The identity provider already logs access changes. The CI/CD pipeline already records every deployment with an approver. The endpoint tool already shows patch status. The vulnerability scanner already produces weekly reports. The SIEM already retains alerts. Readiness work organizes this existing output into evidence packages mapped to specific controls.

Frequently Asked Questions

We already do MFA everywhere. Why does the auditor still want documentation?

The auditor's job is to evaluate the design and operation of the control, not to confirm the technology is configured. A documented access control policy explains who is responsible, what the rules are, when they are reviewed, and how exceptions are handled. The MFA configuration is one piece of evidence that the documented control operates. Without the policy, the auditor has no defined control to test against.

Can we get SOC 2 with just tooling and screenshots?

No. SOC 2 requires documented policies and procedures as part of the Common Criteria, particularly CC1 and CC2. Tooling and screenshots are evidence that controls are operating, but the auditor still needs to see the written control descriptions those screenshots support. A program with strong tooling and no documentation will fail the design review before operation testing even starts.

How long does it take to document an existing security program?

For a security vendor with mature technical practices, four to eight weeks of focused work, often in parallel with GRC platform configuration. The variable is not writing time but the internal review and approval cycle. Teams that designate a single owner and run weekly working sessions move faster than teams that try to fit it around other work.

Should engineering write the policies?

Engineering should be the source of truth for what the controls actually do, but they are usually not the right team to draft and maintain policy documents. The efficient pattern is for an internal owner or a consultant to draft from interviews with engineering, then have engineering review for accuracy. It keeps engineering focused on engineering and produces a more readable document for the auditor.