Every compliance framework, SOC 2, ISO 27001, CMMC, HIPAA, asks the same fundamental question: does this organization have an effective security program? The framework provides the lens. The program provides the answer.
Companies that understand this build the program once and map it to whatever framework their buyers, regulators, or contracts require. Companies that do not understand this build for each framework separately, rewriting policies, re-collecting evidence, and scrambling every time a new requirement appears. The first approach scales. The second one creates perpetual compliance debt.
This is the single most important architectural decision in compliance: build the program first, then map frameworks onto it.
A security program is the system by which an organization protects its information, systems, and operations. Not a binder of policies. Not a GRC dashboard. Not the act of passing an audit. The program is the operating function that runs continuously, producing compliance as a byproduct.
In ISO 27001 terminology, this is called an Information Security Management System (ISMS). The concept is the same regardless of what you call it: a structured, documented, and continuously operated system that covers how security decisions are made, who owns them, what controls are in place, and how effectiveness is measured.
A working security program includes
The distinction between a program and a project is critical. A project has a start date and an end date. A program runs continuously. Companies that treat compliance as a project (spin up, pass the audit, spin down) find themselves rebuilding the same thing every cycle. Companies that treat it as a program get stronger each cycle because the infrastructure persists and improves.
The test
If your CTO left tomorrow, would the security program keep running? If the answer is no, you have a person, not a program. Programs run on cadence, not on whoever has time.
Frameworks do not define your security. They describe and test it. This distinction changes how you approach compliance entirely.
SOC 2 evaluates your program against Trust Services Criteria. ISO 27001 evaluates it against Annex A controls. CMMC evaluates it against NIST SP 800-171 practices. Each framework uses a different lens, but they are all looking at the same underlying program.
When the program is the source of truth
When the framework drives the program
A comprehensive security program typically covers 15 to 20 security domains. The exact taxonomy varies, but the core domains are consistent across frameworks:
Governance and Risk
Risk assessment, risk register, treatment plans, security committee, executive reporting
Access Management
Provisioning/deprovisioning, RBAC, privileged access, access reviews on defined cadence
Network and Endpoint Security
Firewall management, segmentation, EDR/antivirus, device management, encryption, patch management
Application Security
Secure development practices, code review, dependency scanning, deployment controls
Data Protection
Encryption standards, retention and disposal, backup and recovery, classification
Monitoring and Incident Response
Centralized logging, alerting, SIEM, incident response procedures, post-incident review
Business Continuity
DR plans, RTO/RPO definitions, backup testing, continuity exercises
Vendor Management
Third-party risk assessment, vendor security reviews, contractual requirements
People and Physical Security
Background checks, security awareness training, facility access, visitor management, offboarding
Not every domain needs the same depth
A software company with no physical infrastructure needs minimal physical security controls. A company handling health data needs deeper data protection controls. The program should be proportionate to the company's actual risk profile, not a copy of a generic template.
The relationship between an ISMS (the program structure) and SOC 2 (the audit framework) is direct:
| ISMS Domain | SOC 2 Mapping |
| Risk assessment | CC3 (Risk Assessment) |
| Access management | CC6.1, CC6.2 (Logical and Physical Access) |
| Change management | CC8.1 (Change Management) |
| Monitoring and incident response | CC7 (System Operations), CC7.3/CC7.4 (Incident Management) |
| Vendor management | CC9 (Risk Mitigation) |
A company with a functioning ISMS is already doing most of what SOC 2 requires. The audit preparation becomes a mapping exercise, not a building exercise. The same principle applies to ISO 27001 (which literally requires an ISMS) and CMMC (which evaluates the same controls through a different assessment methodology).
Start with what you have. Most companies are already doing security work, they just have not formalized it. Access reviews happen informally. Patching runs on autopilot. Someone handles incidents when they occur. The first step is documenting what already exists, not building from scratch.
Assess maturity, not just presence. For each security domain, evaluate where you stand on the maturity scale: not in place, in place but not effective, effective but not provable, effective and provable. Most companies find they have controls that are effective but not provable. The evidence trail was never designed. Closing this gap is often the highest-ROI activity.
Prioritize by risk and compliance requirements. If SOC 2 is the immediate goal, prioritize the domains that map to Trust Services Criteria. If ISO 27001 is required, start with the ISMS governance structure. If both are needed, build the governance structure first and map downward.
Choose a GRC platform early. Compliance automation platforms like Secureframe, Vanta, or Drata serve as the system of record for the program. They track control status, automate evidence collection, and manage framework mappings. The platform is essential, but it does not replace the program design. Someone still has to define the controls, write the policies, assign the owners, and operate the cadence.
Document in a Security Program Manual. The manual is the operational playbook: how every security domain is run, by whom, to what standard, on what cadence. It covers what the GRC platform cannot automate (typically 40-60% of controls require manual process and ownership). This document becomes the single source of truth that auditors, buyers, and internal teams reference.
A security program that only activates during audit season is not a program. It is a recurring project. The difference is cadence.
A working program runs on a defined rhythm
This cadence produces evidence continuously. When audit time arrives, the evidence already exists. The audit preparation work is packaging and mapping, not generating.
Incidents and testing are feedback loops
Mature programs get stronger from real-world input. A penetration test finding becomes a control improvement. An incident becomes a procedure update. A near-miss becomes a training topic. This feedback loop is what separates a living program from security documentation that sits on a shelf.
As your fractional security team and vCISO, we build and operate security programs that stay audit-ready without the quarterly scramble.
Book a Strategy CallAn ISMS (Information Security Management System) is the ISO 27001 term for a structured security program. The concepts are functionally identical: a systematic approach to managing security through policies, controls, ownership, and continuous improvement. Every security program is effectively an ISMS whether or not it is formally called one.
SOC 2 does not require a formal ISMS, but the underlying structure is the same. SOC 2 evaluates whether you have effective controls across the Trust Services Criteria. A well-structured security program makes SOC 2 compliance significantly easier because the controls, evidence, and operating cadence are already in place.
The program is the source of truth. Each framework is a lens that evaluates specific aspects of the program. Access management controls serve SOC 2 CC6.1, ISO 27001 A.9, and CMMC AC.L1-3.1.1 simultaneously. When the program generates evidence as standard operating output, that evidence serves all mapped frameworks without duplication.
For companies with existing informal security practices, formalizing into a documented program typically takes 2 to 4 months. Building from scratch with no existing controls takes 4 to 6 months. The program then operates continuously, with each audit cycle becoming more routine as the operating cadence matures.
A GRC platform (Secureframe, Vanta, Drata) is the technology that tracks control status, automates evidence collection, and manages framework mappings. The security program is the complete system: policies, controls, ownership, processes, and operating cadence. The platform supports the program but does not replace it. Approximately 40-60% of controls require manual process and human ownership that the platform cannot automate.
Yes. This is the most efficient approach. Build the security program as a single system covering all relevant security domains, then map each framework onto it. Adding a framework to an existing program is typically 20-30% incremental effort compared to building for each framework separately.
Controls can be assessed on a four-level maturity scale: not in place, in place but not effective, effective but not provable, and effective and provable. Most companies find that many controls fall in the third category: the security work is being done, but the evidence trail was never designed. Closing this gap is often the highest-ROI activity in compliance preparation.
It should run on cadence. Let's build the program that makes that real.
Book a Strategy Call