Building a Security Program From Zero: A Twelve Month Plan

What you actually need to know

• The program takes twelve months to reach defensible. Twenty four to mature.
• Start with the threat model. The rest follows.
• The audit is the byproduct, not the goal.
• A senior engineer can lead the program in year one.
• The investment is real but smaller than the cost of failing an enterprise security review.

The core argument

Most SaaS teams treat security as a feature they will add when an enterprise customer asks. The pattern is consistent. The customer asks for SOC 2. The team panics. They scramble to put controls in place. They pass the audit on theater alone. The next customer asks harder questions. The theater does not hold up. The deal does not close.

The teams that get this right treat security as a program, not a checkbox. The program runs on a schedule. The controls are real. The evidence is generated by operating the controls, not by manufacturing artifacts. The audit at month twelve is the byproduct of the work, not the goal.

The investment is real. Forty to eighty thousand USD in the first year for a small SaaS. The cost is mostly external. Audit fees, the automation platform like Vanta or Drata, the penetration test, the security tooling. The engineering time is significant but it is work the team should be doing anyway.

The return is also real. Enterprise deals that would not close without a program. Faster procurement cycles. Lower legal and operational risk. Customers who trust the product because they can see the work.

The twelve month plan

Month one. Write the threat model. Name the program owner. Draft the baseline policies. Information security, acceptable use, access control, incident response. The policies do not have to be perfect. They have to exist and reflect what the team actually does.

Month two. Lock down endpoints. MDM on every laptop. Disk encryption verified. Antivirus or equivalent. Set up secrets management with a vault. Move every API key out of the codebase. Tighten access control. Single sign on. Least privilege.

Month three. Audit logging. Vulnerability scanning. Vendor inventory. The audit log captures sensitive actions. The vulnerability scanner runs on every deploy. The vendor inventory names every third party that touches customer data.

Month four. Incident response plan. On call rotation. Run a tabletop incident. The team should know what to do when something goes wrong. The first tabletop will be rough. The second one will be better. Practice matters.

Month five. Penetration test. Real testers, real scope, real report. The first pen test usually finds things. Remediate them. The cost is real but small compared to the value of knowing.

Month six. SOC 2 readiness assessment. The auditor walks the controls with you. They identify the gaps. The remediation list becomes the next quarter's work.

Month seven. Data classification. Encryption review. Customer data flows mapped. Encryption at rest and in transit verified across every store and every wire.

Month eight. Customer security questionnaire template. The team has a one page answer for every question enterprise customers will ask. The questionnaire becomes a sales asset.

Month nine. Disaster recovery drill. Restore from backup. Measure recovery time and recovery point. Document the results.

Month ten. Vendor security reviews. Every vendor that touches customer data gets reviewed. The reviews are documented.

Month eleven. Pre audit gap close. The auditor returns. They check the remaining items. The team closes the last gaps.

Month twelve. SOC 2 Type I audit. The report ships. The program has its first external validation.

How much does the first year cost

The total external cost for a small SaaS is roughly 40k to 80k USD. The engineering time is the largest internal cost. Both are recoverable from a single enterprise deal that would not have closed without the program.

Features the program must have

• A named owner with executive sponsorship.
• A written threat model that the team has read.
• Baseline policies that match what the team actually does.
• Operating controls with evidence collected automatically.
• A quarterly review of the program.
• A vendor inventory that is current.
• A penetration test on an annual cadence.
• A customer facing trust portal.

Expert opinion

The security programs that succeed are run on schedules. Not in bursts before audits. The teams that run the schedule end up with controls that are real and evidence that is automatic. The teams that try to compress the work to the month before the audit end up with theater that the next auditor catches.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A SaaS client had no security program when their first enterprise prospect arrived. The prospect required SOC 2 Type II in twelve months as a condition of the contract. The team had eight months until that deadline.

We compressed the twelve month plan into eight. Month one was the threat model and baseline policies. Month two was endpoints and secrets. Month three was audit logging and vulnerability scanning. Month four was the incident plan and penetration test. Month five was the readiness assessment. Month six was the data classification and encryption review. Month seven was the disaster recovery drill. Month eight was the Type I audit. The Type II observation period started immediately after.

The contract signed eleven months in. The Type II report shipped at month sixteen. The compressed timeline was punishing for the team but the program survived because the work was real. The customer's security team has audited the program three times since and has not flagged a deficiency.

For more on the related work, see SOC 2 Type I vs Type II and the customer security questionnaire a strategic asset.

Common mistakes teams make

1. Treating SOC 2 as the goal rather than as the byproduct of a real program.
2. Starting the program when the first enterprise prospect arrives.
3. Skipping the threat model. The priorities are reactive.
4. Hiring a security engineer too early. A senior engineer can lead year one.
5. Optimizing for audit theater instead of real controls.
6. No quarterly review. The program drifts.
7. No customer facing trust portal. The work is invisible to buyers.
8. Compressing the timeline to the month before the audit.

A pre program checklist

1. Day one. Get executive sponsorship. Name the owner.
2. Day two. Write the threat model.
3. Day three. Pick the compliance automation platform.
4. Day four. Draft the baseline policies.
5. Day five. Build the twelve month roadmap.
6. Week two. Start month one of the plan.

For more on the related work, read SOC 2 Type I vs Type II and Vanta vs Drata vs Secureframe for SOC 2 automation. On the deeper practical side, the threat model how to build one in two hours is the natural next read.