How to Build a Compliance Program from Scratch in 2026

Learning how to build a compliance program from scratch is the task that kills most first-time heads of compliance. There is no universal starting template, every framework has overlapping requirements, and the same policy has to simultaneously survive SOC 2 field testing, a HIPAA risk assessment, a customer security questionnaire, and a cyber insurance underwriting call. The real question is not "what framework" but "what program architecture makes every framework easier."

This guide gives SaaS founders, startup CTOs, and first-time compliance leads the 10-step blueprint I have used to build security and compliance programs at SaaS and healthcare-adjacent companies for the past eight years. The sequence matters. Building policies before you have a risk assessment produces policies nobody follows. Building controls before you have policies produces unauditable workflow. Building evidence collection before you have controls produces storage bills with no audit value.

Why You Need a Formal Compliance Program

Informal compliance fails the moment the auditor walks in. Informality means no named owner for each control, no cadence, no evidence trail, and no way to demonstrate operating effectiveness over time. In a SOC 2 Type 2, informality translates directly into a qualified opinion.

Three concrete business outcomes demand a formal program:

• Enterprise sales velocity. Buyers' security questionnaires map directly to program artifacts. A formal program means the questionnaire is answered in days, not weeks. See our analysis of the full path in SOC 2 for SaaS startups.
• Cyber insurance underwriting. Carriers now require evidence of a mature program to bind. A documented program shortcuts underwriting by 3 to 6 weeks and often reduces premium by 10 to 25 percent.
• Breach defensibility. If you have an incident, regulatory and civil defense rest on whether your program was reasonable. "Reasonable" is a documented, tested, governed program with current risk assessments, policies, training, and monitoring evidence.

Companies that delay program build until the first enterprise deal stalls end up paying 3x the cost of the program they would have built proactively, plus the opportunity cost of the stalled deal.

The 10-Step Compliance Program Blueprint

External references: NIST SP 800-30 Risk Management Guide for the risk assessment methodology, the AICPA Trust Services Criteria for SOC 2 mapping, and the HHS HIPAA Security Rule for healthcare obligations.

Step 1: Write the Program Charter

The charter is a 3 to 5 page document signed by the CEO (or equivalent executive sponsor) that establishes three things: the scope of the program, the accountability, and the authority.

Scope answers: which frameworks does this program cover (SOC 2, HIPAA, ISO 27001, PCI DSS, NIST CSF, or a subset)? Which legal entities and business units? Which data classifications? Which geographies?

Accountability answers: who is the executive sponsor, who is the program owner, which committee approves policies, who can declare an incident?

Authority answers: what can the program owner require of engineering, HR, finance, and sales without escalation? What decisions must be escalated to the committee? Who breaks ties?

The charter is not a long document, but it is the single reference that stops "that's not in my team's scope" from derailing every project. Revise it annually and re-approve at the executive level.

Step 2: Map Your Legal and Contractual Obligations

Before picking a framework, list every obligation that binds the company. This is boring work that pays off across the next nine steps.

Typical sources include:

• Laws. HIPAA, GLBA, SOX, CCPA/CPRA, GDPR, FERPA, PCI DSS as contractually binding, state breach-notification laws, state privacy laws
• Customer contracts. Security addendums, BAAs (see HIPAA BAA guide), data processing agreements, MSA security riders
• Cyber insurance policies. Warranty and application representations create contractual obligations
• Industry standards. PCI DSS for card processors, HITRUST for healthcare IT, IRS 1075 for taxpayer data, CJIS for criminal justice data
• Voluntary attestations. Commitments made in marketing materials, on trust pages, or in RFP responses

Load the obligations into a single matrix with the source, the specific requirement, the owner, and the current status. This matrix becomes the input to Step 4 (framework selection) and Step 6 (control design).

Step 3: Run a Baseline Risk Assessment

The risk assessment is the document that drives every prioritization decision in the program. It must come before the policy set, not after.

A defensible risk assessment follows the NIST SP 800-30 methodology:

• Asset inventory. Every system, data store, third party, and facility that handles in-scope data
• Threat identification. For each asset, the realistic threat actors (insider, external criminal, nation state, supply chain, natural disaster)
• Vulnerability identification. Known weaknesses by asset and threat
• Likelihood and impact assessment. Quantitative where possible, qualitative where not
• Risk scoring and prioritization. High / Medium / Low or equivalent numeric scale
• Risk treatment decisions. Accept, mitigate, transfer, or avoid each identified risk, with owner and deadline

Output this as a single risk register. Approve it at the committee level and update it quarterly. OCR, SOC 2 auditors, and ISO 27001 registrars all request the current risk assessment as the first document in fieldwork. If it is missing, stale, or generic, everything downstream is compromised.

For framework-specific templates, the HIPAA risk assessment guidance and the ISO 27001 internal audit guide both apply the same underlying methodology.

Step 4: Choose the Framework (or Frameworks)

Now that you know your obligations and your risk posture, pick the primary framework. The practical options in 2026:

• SOC 2 Security only. The default starting point for any B2B SaaS selling into mid-market or enterprise. See SOC 2 compliance checklist.
• HIPAA Security and Privacy Rules. Mandatory for any organization that handles PHI, whether CE or BA. Often layered underneath SOC 2.
• ISO 27001:2022. International equivalent of SOC 2. Preferred outside North America and for organizations with European enterprise customers.
• NIST CSF 2.0. Framework, not an attestation. Widely used as the control architecture that supports SOC 2 or ISO 27001 output. See NIST CSF vs ISO 27001.
• PCI DSS 4.0. Mandatory for any entity that stores, processes, or transmits cardholder data. See PCI DSS 4.0 requirements.
• CMMC 2.0 / NIST 800-171. Required for Department of Defense contractors. See NIST 800-171 compliance guide.

Pick one primary framework. Layer additional frameworks only when a specific legal or contractual obligation requires it. For a side-by-side comparison across the major frameworks, see SaaS compliance frameworks.

Step 5: Build the Policy Framework

The policy framework is the set of governing documents that define how the company will operate to meet its obligations. Most SOC 2 and ISO 27001 programs require 15 to 25 distinct policies, including:

• Information security policy (master document)
• Acceptable use
• Access control
• Password and authentication
• Data classification and handling
• Encryption and key management
• Vulnerability management
• Change management
• Incident response
• Business continuity and disaster recovery
• Vendor and third-party risk management
• Secure software development lifecycle
• Physical security
• Human resources security (hiring, onboarding, offboarding, background checks)
• Privacy policy (external-facing plus internal handling)
• Mobile device / BYOD
• Remote work
• Asset management
• Logging and monitoring
• Risk management
• Compliance and audit

Three rules for policy drafting:

1. Own the words. Compliance platforms ship pre-drafted policies. Read every line. Delete anything you will not enforce. The worst auditor finding is a policy whose author cannot answer questions about its content.
2. Map controls to policies, not policies to controls. The policy is the obligation; the control is how you meet it. Never write a policy to match an existing hack.
3. Review and re-approve annually. Every policy needs a dated approval signature. Stale approval dates are a recurring auditor finding.

Step 6: Design the Control Set

Controls are the specific, testable activities that implement the policies. A control has five required attributes: a named owner, a cadence, a trigger, a procedure, and an evidence artifact.

Typical first-program control count is 80 to 150, covering:

• Governance. Risk assessment, policy approval, management review, audit
• Logical access. User access review, privileged access management, SSO enforcement, MFA
• Change management. Code review, deployment approval, separation of duties
• System operations. Patch management, backup, log review, vulnerability scanning, penetration testing
• Incident response. Detection, triage, containment, notification, post-incident review
• Third-party risk. Vendor onboarding, BAA execution, annual re-review
• Human resources. Background checks, onboarding, offboarding, security awareness training
• Physical security. Facility access, visitor log, asset disposal

Map each control to the framework(s) it satisfies. A single control (quarterly user access review) can satisfy SOC 2 CC6.2, HIPAA 164.308(a)(4), ISO 27001 A.5.18, and PCI DSS 7.1.1 simultaneously. The mapping is the leverage: one well-run control satisfies many obligations.

For concrete control sets, see the SOC 2 compliance checklist, NIST 800-53 controls, and ISO 27001 Annex A controls.

Step 7: Implement Evidence Collection

Evidence is the record that a control actually ran. Without evidence, a control does not exist for audit purposes. This is the step where compliance automation platforms earn their keep.

Evidence comes in two forms:

• Automated evidence. Continuous API-based collection from cloud providers, SaaS systems, and the ticketing stack. Examples: SSO config snapshots, MFA enforcement reports, patch status, backup logs, IaC deployment records.
• Manual evidence. Screenshots, signed attestations, policy approval emails, tabletop exercise reports, training completion records. The work that cannot be automated.

The deliverable per control per cycle is a timestamped artifact (file, link, screenshot) stored in a centralized location: the compliance platform, SharePoint, a dedicated audit drive. Retention is framework-specific, but seven years is the safe default for most B2B programs (covers the six-year HIPAA retention plus SOC 2 rolling multi-year).

Automate aggressively in year one. Every manual evidence task is a year-round drag on the engineering and compliance teams.

Step 8: Train the Workforce

Training is not a checkbox; it is the single largest control surface in the program. Most incidents trace back to a human action (clicked a phishing link, sent PHI to a personal email, bypassed the change management workflow).

Minimum training components:

• New-hire onboarding. Security and privacy basics within 30 days of hire, documented completion
• Annual security awareness. All staff, all frameworks
• Role-based training. Engineering on secure coding, finance on wire fraud, HR on PHI handling, support on impersonation defenses
• Phishing simulation. Monthly or quarterly cadence with remedial training for repeat clickers
• Incident response drill. Annual tabletop with the executive team and the security function

Document completion at the individual level, retain records for at least the framework retention period, and report training rates to the executive committee quarterly. For healthcare-specific training, see HIPAA training requirements.

Step 9: Establish the Audit Cadence

The cadence is what turns a static program into continuous compliance. Without cadence, the program rots between audits.

Recommended cadence for a mid-market program:

• Daily. Automated evidence collection, alert triage, ticket review
• Weekly. Access exception handling, incident review
• Monthly. Key control testing, vendor risk queue, vulnerability scan review, phishing results
• Quarterly. User access review, policy exception review, management risk review, internal audit sampling, tabletop exercise
• Semi-annually. Business continuity test, penetration test (also a PCI DSS penetration testing requirement)
• Annually. Risk assessment refresh, policy review and re-approval, program charter re-approval, framework audit (SOC 2 Type 2, ISO 27001 surveillance, HIPAA risk assessment)

Assign each cadence item an owner, a backup, and a due date. Track completion in the same ticketing system the engineering team uses. Missed cadence is the first-sign of program decay.

For internal audit methodology specifically, see our ISO 27001 internal audit guide — the sampling approach transfers directly to SOC 2 internal audit.

Step 10: Continuous Improvement and Governance

A compliance program is a process, not a state. Continuous improvement requires three standing activities:

Governance committee. Quarterly minimum. Executive sponsor, program owner, legal, engineering leadership, HR leadership. Reviews the risk register, incident log, audit findings, and metric dashboards. Approves material policy changes. The governance minutes are audit evidence.

Metrics and KPIs. Track at least: mean time to detect incidents, mean time to remediate audit findings, policy exception count and age, access review completion rate, phishing click rate, training completion rate, vendor review queue age. Report monthly to the program owner, quarterly to the committee.

Continuous improvement log. Every audit finding, incident, and near-miss generates a lessons-learned entry with an owner, deadline, and verification step. The log is the single reference auditors use to test whether the program actually improves over time.

The governance and improvement machinery is what separates a program that passes its next audit from a program that erodes between audits.

Typical First-Year Timeline

A realistic first-year build timeline for a 20 to 100-person SaaS:

• Month 1: Program charter, obligation mapping, executive sponsor
• Month 2-3: Baseline risk assessment, framework selection, automation platform selection
• Month 3-5: Policy drafting and approval, control design
• Month 5-8: Control implementation, evidence collection build-out, workforce training rollout
• Month 8-10: Internal audit, remediation, auditor selection
• Month 10-12: First audit fieldwork (Type 1 or compressed Type 2), report issuance

Compressing this timeline is possible with a compliance platform and dedicated staffing. Expanding it past 15 months usually signals missing executive sponsorship, which is a Step 1 problem masquerading as a later-stage problem.

Budget for the first year typically runs $50,000 to $150,000 all-in at the SaaS scale described above. See our SOC 2 audit cost guide for the detailed breakdown.

Common Mistakes to Avoid

Starting with policies. Policies without a risk assessment and control design produce documents nobody follows. Risk assessment first, always.

Copying a competitor's program. Their obligations are not your obligations. Mapping Step 2 is irreplaceable.

Over-scoping in year one. Adding HIPAA, SOC 2, ISO 27001, PCI DSS, and CMMC simultaneously in year one produces a program that passes nothing. Pick one primary framework.

Hiring the audit firm as consultant. Independence impairment issues block them from being both. Use a separate advisory firm or a compliance platform for buildout.

Treating the program as a one-time project. Without ongoing cadence and governance, the program decays within 18 months and year-two audits produce qualified opinions.

Outsourcing ownership to a vendor. The compliance platform can automate evidence; it cannot own the program. A named internal owner is non-negotiable.

Frequently Asked Questions

How long does it take to build a compliance program from scratch?

A realistic timeline for a first SOC 2 Type 2 or ISO 27001 certification at a 20 to 100-person SaaS is 10 to 14 months. A Type 1 or a limited-scope internal audit can be delivered in 6 to 9 months. Faster timelines exist but usually produce programs that cannot sustain year-two renewals.

How much does it cost to build a compliance program from scratch?

First-year all-in cost for a B2B SaaS startup typically runs $50,000 to $150,000, including the compliance automation platform, audit fees, remediation tooling, external advisory, and internal labor. Year two drops by 30 to 50 percent as remediation is complete.

Do I need a dedicated compliance hire?

Below 100 employees, a shared role (often VP of Engineering or Head of Security plus a fractional compliance consultant) can work if the scope is one framework. Above 100 employees or across multiple frameworks, a dedicated compliance lead pays for themselves through reduced audit findings and faster sales cycles.

Which framework should I start with?

For B2B SaaS selling to US enterprise, start with SOC 2 Security only. For healthcare SaaS, layer HIPAA underneath. For EU or global enterprise, consider ISO 27001:2022 as the primary with SOC 2 as a secondary. Pick one primary framework, not three.

What does a compliance program cost after year one?

Year two and beyond typically run $30,000 to $80,000 per year for a B2B SaaS at the same scale, covering the compliance platform, annual audit, penetration test, training, and ongoing tooling. Adding additional frameworks raises the cost but the marginal framework is always cheaper than the first.

How do I know my program is working?

Four leading indicators: audit findings trend down year over year, access review completion rate stays above 95 percent, mean time to remediate audit findings stays under 30 days, and security questionnaire turnaround drops from weeks to days. A program that is not improving on these is decaying.

What's the difference between compliance and security?

Security is the operational capability to protect systems and data. Compliance is the documented evidence that you are doing security in a structured, auditable, obligation-aligned way. A mature security team can be non-compliant (no documentation). A compliance program without real security is an audit-only posture that fails the first incident. You need both.

The Takeaway

A compliance program is not a binder, a certificate, or a platform. It is a sustained operating rhythm with named owners, a documented risk basis, controls that actually run, evidence that actually accumulates, and governance that actually meets. Build it in the sequence described here and year-two renewals become routine. Skip steps and year two becomes year one all over again.

For the concrete control-level sequence across specific frameworks, start with SOC 2 compliance checklist for North American SaaS, the HIPAA compliance guide for healthcare, or the ISO 27001 Annex A controls for international programs. The 10 steps above apply to all three.