Cyber, Data Privacy, and Security
Module 12 is the security and compliance layer of the operating system. It embeds cybersecurity, data privacy, and incident readiness into daily operations rather than treating them as IT afterthoughts or annual audit exercises.
Module 12 receives its primary upstream signal from Module 1's AI Readiness Index. A red score on compliance baseline compresses response windows from 72 hours to 24 hours and escalates customer PII to Restricted classification by default. The diagnostic does not flag a problem and wait. It triggers immediate governance changes in Module 12.
Module 12 also receives signals from Module 4 (Integrated Tech Stack) and Module 7 (AI Deployment Canvas). Module 4 provides system inventory and data blueprints for threat modeling. Module 7 triggers a Privacy Impact Assessment for every new AI deployment. Every system integration and AI model routes through Module 12 governance before launch.
Downstream, Module 12 security KPIs feed Module 3 as part of the operational dashboard. Module 12 compliance posture feeds Module 9 as a valuation driver. Module 12 data classification rules constrain Module 7: Restricted-tier models face higher governance than Internal-tier models.
No other mid-market operating system includes a dedicated security module. EOS ignores cybersecurity. Scaling Up ignores data privacy. OKR frameworks ignore incident response. For regulated industries and companies handling sensitive data, this is not a feature gap. It is a risk gap.
Why Security Programs Fail in Mid-Market Companies
Cybersecurity breaches cost mid-market companies far more than the direct financial loss. The cost includes customer trust, regulatory penalties, and operational disruption that can take years to recover from.
Pattern 1: Security as an IT problem. The business treats security as a technology function. The IT team manages firewalls and patches. Nobody else thinks about it. When a breach occurs, the business discovers that security is an operational problem, not a technical one. The phishing email that got through targeted a sales rep, not a server.
Pattern 2: Compliance-driven instead of risk-driven. The company does what regulations require and nothing more. GDPR consent banners go up. SOC 2 Type II audit passes. The compliance checkbox is checked. But the threat model has not been updated in two years, the incident response plan has never been tested, and the data classification matrix does not exist. Compliance is a floor. The company is standing on it with nothing above.
Pattern 3: Static threat assessment. The company conducted a risk assessment when it was founded or when it raised funding. The assessment sits in a document. The threat landscape has changed three times since then. New attack vectors (AI-powered phishing, supply chain compromise, API exploitation) are not reflected. The assessment is a historical artifact, not a governance tool.
Module 12 addresses all three patterns through an operational approach to security (not IT-only), a risk-driven threat model that updates quarterly (not compliance-only), and continuous monitoring through security KPIs (not static assessments).
Dynamic Threat Model Canvas
What it does
The Threat Model Canvas is a living document that maps and prioritizes security threats on a continuous basis. It replaces the static annual assessment with a quarterly full review and real-time updates when new threat intelligence emerges.
Canvas dimensions
Threat actors. External hackers, insider threats, third-party vendors, and nation-state actors. Each category is assessed separately because they require different defense strategies.
Attack vectors. Phishing, ransomware, supply chain compromise, social engineering, and API exploitation. The vector landscape evolves faster than any other dimension, which is why quarterly review is mandatory.
Asset inventory. Critical systems, data stores, customer data repositories, and intellectual property. This dimension draws directly from Module 4's System Inventory Sheet. The assets are already cataloged. Module 12 assesses their vulnerability.
Vulnerability assessment. Known CVEs, configuration gaps, and human factors. The human factor dimension connects to Module 10 (Change Enablement Sprint), where security awareness training is delivered through the moment-of-need framework.
Impact scoring. Financial, operational, reputational, and regulatory impact for each threat scenario. Impact scores feed into Module 8's risk assessment for funded projects. A project with high security risk may require additional budget for Module 12 compliance measures.
Output
A prioritized risk register with mitigation owners and timelines. The register is reviewed at the Monthly Capital Governance Forum (Module 8) when security-related investments are on the agenda.
Smart Data Classification Matrix
What it does
The classification matrix categorizes every data asset in the organization by sensitivity tier, with handling rules, storage requirements, and compliance mapping for each tier.
Four tiers
Public. Marketing materials, published content. No restrictions.
Internal. Business operations data, non-sensitive employee information. Standard access controls.
Confidential. Financial data, customer PII, contracts. Encrypted storage, role-based access.
Restricted. Trade secrets, health records, payment data. Highest encryption, strict need-to-know access, full audit trail.
How Module 1 adjusts classification
When Module 1's AI Readiness Index scores red on compliance baseline, Module 12 escalates the default classification for all customer personal data to Restricted tier. This means encrypted storage, strict access controls, and full audit trails activate automatically. The classification does not wait for a manual review. The system responds to the diagnostic.
Connection to Module 7
The classification matrix directly constrains Module 7's AI deployments. An AI model that needs access to Restricted-tier data faces additional governance requirements: more stringent bias audits, mandatory human-in-the-loop for predictions that use Restricted data, and additional encryption requirements for data in transit to the model.
Module 7's scoring grid includes a Data Sensitivity dimension. That dimension is scored using Module 12's classification matrix. The two modules are interdependent: Module 7 governs the AI tools, and Module 12 governs the data those tools consume.
Labeling and automation
Data is classified at creation through automated tagging. Manual override requires an approval workflow. The goal is that every employee knows the classification of the data they touch daily. This is not a one-time classification project. It is a continuous system maintained through Module 2's SOP Codex (the classification process is itself a documented SOP) and Module 10's micro-training (security awareness assets teach employees how to classify data they create).
Three-Tier Incident Response Runbook
What it does
The runbook provides a structured response framework for security incidents, organized by phase and time constraint.
Tier 1: Detection and Triage (0 to 1 hour)
Automated alert from SIEM or monitoring tools. Initial severity assessment (Critical, High, Medium, Low). Containment decision: isolate affected systems if Critical or High. Notify incident commander and assemble response team. Begin evidence preservation (logs, snapshots).
Tier 2: Investigation and Response (1 to 24 hours)
Root cause analysis. Scope determination (what data or systems affected, how many users). Eradication of threat. Communication to internal stakeholders, legal counsel, and PR if needed. Regulatory notification assessment.
How Module 1 adjusts response windows
When Module 1 scores red on compliance baseline, the regulatory notification window compresses from 72 hours (standard GDPR requirement) to 24 hours. This conservative posture gives the organization a safety margin. If the compliance infrastructure is weak, the system compensates by requiring faster response.
Tier 3: Recovery and Post-Incident (24 hours to 2 weeks)
System restoration and verification. Enhanced monitoring of affected areas. Post-incident review (what happened, why, how to prevent recurrence). Runbook update based on lessons learned. Employee communication and retraining through Module 10 if human factor was involved. Insurance claim initiation if applicable.
Tabletop exercises
Quarterly simulation of each tier using realistic scenarios. The exercises use Module 10's adoption framework: pre-exercise briefing, during-exercise observation, post-exercise debrief with lessons learned. The exercise results feed Module 12's Incident Response Readiness score.
Escalation matrix
Clear chain of command with backup contacts for every role. The matrix is maintained as an SOP in Module 2's codex with the standard 90-day review cycle.
Privacy Impact Assessments
What they do
PIAs evaluate the impact of data processing activities on privacy, identifying and mitigating privacy risks before deployment.
Trigger events
New system deployment (Module 4). New data collection initiative. New third-party integration (Module 4 change control). New AI model deployment (Module 7). Each trigger routes through Module 12 before the new system, collection, integration, or model goes live.
Assessment framework
What personal data is collected and why. Legal basis for processing (consent, legitimate interest, contractual necessity). Data flow mapping (where data goes, who accesses it, cross-border transfers). Risk identification (unauthorized access, data loss, purpose creep). Mitigation measures (encryption, access controls, anonymization, retention limits).
Connection to Module 9
Completed PIAs are stored in the compliance repository and available for regulatory audit. When Module 9 assembles the diligence package for a transaction, the PIA history demonstrates privacy maturity. An acquirer can see every data processing decision, every risk assessment, and every mitigation measure. This documentation reduces perceived compliance risk in M&A transactions.
Essential Security KPIs
Four categories
Detection metrics. Mean Time to Detect (MTTD) measures how quickly threats are identified. False positive rate measures the signal-to-noise ratio of alerting systems.
Response metrics. Mean Time to Respond (MTTR) measures how quickly threats are contained. Mean Time to Recover measures how quickly operations return to normal.
Prevention metrics. Patch compliance rate (percentage of systems current within SLA). Phishing simulation click rate (employee awareness indicator). Vulnerability scan findings trending (open versus closed over time).
Compliance metrics. Audit finding closure rate. PIA completion rate for new initiatives. Training completion rate for security awareness.
Connection to Module 3
Security KPIs integrate into the same traffic-light dashboard system used across all VWCG OS modules. A red MTTD triggers Module 3's Variance Alert Engine, which routes the signal to the CISO and COO. Monthly reporting to CISO and COO. Quarterly reporting to the board.
This integration means security metrics receive the same attention as sales metrics (Module 6), financial metrics (Module 8), and people metrics (Module 11). They are not buried in an IT report. They are on the operational dashboard where leadership sees them weekly, with formal monthly reporting to the CISO and COO.
What Makes This Different from Standard Security Programs
Standard cybersecurity programs (NIST Cybersecurity Framework, ISO 27001, SOC 2 Type II) provide excellent control frameworks and audit standards. They are designed as horizontal programs that apply to any organization.
Module 12 is a vertical security layer embedded in the operating system. Three differences stand out.
First, Module 1's diagnostic sets governance intensity. Red on compliance baseline triggers automatic changes: tighter classification, compressed response windows, increased audits. Standalone programs base intensity on risk assessments. Module 12 bases it on diagnostics across 14 dimensions.
Second, every other module routes through Module 12 for data and security governance. Module 4's new integrations trigger PIAs. Module 7's AI deployments are constrained by data classification. Module 2's SOPs include security procedures. Module 10's training library includes security awareness assets. The security layer is not a separate program. It is woven into every module.
Third, the security posture feeds directly into Module 9's exit readiness. Every threat model update, every PIA, every incident response, and every tabletop exercise is documented and audit-ready. The security program is simultaneously an operational necessity and a valuation driver.
Who This Module Is For
Module 12 was designed for mid-market companies that handle customer data, operate in regulated industries, or are preparing for the compliance requirements that come with continued scaling.
These companies often have basic security measures: firewalls, antivirus, and access controls. What they lack is the operational discipline of continuous threat modeling, structured incident response, privacy impact assessment as a routine process, and security metrics that sit alongside financial and operational metrics on the leadership dashboard. Module 12 provides that discipline as part of the operating system, not as a separate initiative.
The Working Specification
The instrument scores five dimensions: Threat Model Currency, Data Classification Enforcement, Incident Response Readiness, PIA Gating, and Security KPI Integration. Weights are version 1.0 calibration defaults from 2026-08-20, tuned to each client during calibration.
The Instrument
The Cyber, Data Privacy, and Security Diagnostic scores 5 dimensions on a 0 to 5 scale against written anchors. The composite score is a weighted sum with equal weights of 0.20 per dimension. Four published metric groups carry the page rules. Detection, response, and recovery means are tracked, and red MTTD triggers the M03 Variance Alert Engine to the CISO and COO. Prevention covers patch compliance within SLA and the phishing simulation click rate. Every new system, collection, integration, or AI model completes a PIA before go-live. The regulatory notification window runs 72 hours standard and compresses to 24 hours on M01 compliance-baseline red.
| Dimension | Weight | What it measures | Score 1 | Score 3 | Score 5 |
|---|---|---|---|---|---|
| Threat Model Currency | 0.20 | Threat Model Canvas covers actors, vectors, asset inventory from M04, vulnerabilities including human factors, and impact scoring. Quarterly full review plus real-time updates on new intelligence. Prioritized risk register with owners and timelines, reviewed at the M08 Forum when security spend is on the agenda | Static founding-era assessment. New vectors like AI phishing, supply chain, and API unreflected | Canvas exists. Quarterly review slips. Register owners unclear | Quarterly reviews kept. Register current with owners and timelines. Impact scores feed M08 project risk |
| Data Classification Enforcement | 0.20 | All data assets tiered Public, Internal, Confidential, Restricted with handling rules. Classification at creation via automated tagging with an approval workflow for overrides. M01 compliance red escalates customer personal data to Restricted automatically. M07 sensitivity scores drawn from this matrix | No classification matrix. Handling ad hoc | Matrix defined. Tagging partial. AERI escalation manual | Auto-tagging with override workflow. Restricted default fires on M01 red without manual review. M07 constraints enforced for Restricted-tier models |
| Incident Response Readiness | 0.20 | Runbook covers Tier 1 (0 to 1 hour triage), Tier 2 (1 to 24 hours investigation), Tier 3 (24 hours to 2 weeks recovery). Windows compress on M01 red. Quarterly tabletop exercises across tiers using the M10 framework with results scored in Incident Response Readiness. Escalation matrix is a coded M02 SOP on the 90-day review | No runbook or untested plan. First incident is the first rehearsal | Runbook documented. Tabletops irregular. Matrix stale | Quarterly tabletops run with lessons fed back into the runbook. Windows honored in exercises. Matrix current in M02 |
| PIA Gating | 0.20 | All four trigger events route through PIA before go-live: new system, new collection, third-party integration, new AI model. Assessments use the five-part framework: data and purpose, legal basis, flow mapping, risks, mitigations. Completed PIAs stored audit-ready for M09 | PIAs never happen. Deployments go live unassessed | PIAs happen for some triggers. Repository incomplete | No go-live without a completed PIA. Repository complete and diligence-ready. Zero bypasses logged |
| Security KPI Integration | 0.20 | Detection, response, prevention, and compliance KPIs live on the M03 dashboard with traffic-light thresholds. Red MTTD routes to CISO and COO. Monthly CISO and COO reporting and quarterly board reporting held | Security metrics buried in IT reports or nonexistent | KPIs on the dashboard. Reporting cadence slips | All four categories live with alert routing. Monthly and quarterly reporting uninterrupted. Security metrics reviewed alongside sales, capital, and people metrics |
Scoring and Bands
| Band | Range | What it routes to |
|---|---|---|
| Red | 0.0 up to but not including 2.0 | Proposes the owning remediation playbook. Safety routes act on the first reading (Routing table below) |
| Amber | 2.0 to 3.5 inclusive | PB-M12-04 monitoring with 30-day pulse checks |
| Green | above 3.5 up to and including 5.0 | Hold and monitor quarterly through M13 |
The detection and response means, prevention metrics, PIA completion rule, and response window carry the published thresholds listed above.
Routing
Red bands fire the routes below. Every amber dimension routes to PB-M12-04. Green dimensions hold and are monitored quarterly through M13, event-driven for the PIA status signal. Conditions read the module 0 to 5 bands unless a row names another scale. A color changes only when a score clears the band edge by a margin, or holds for two consecutive scorings. The margin is 0.25 points on 0 to 5 scales and 5 points on the AERI 0 to 100 scale. Safety routes are the routes that set AI mode in any module, the Privacy Impact Assessment rule, or Module 12 classification and response windows. They tighten on the first reading and loosen only after an independent re-score clears the edge. When two routes set the same parameter differently, the most restrictive value wins for safety routes, and the owning module's value wins for every other parameter. A route that fires from a scored dimension is a proposal until leadership confirms it in the M13 Phase 3 review. Routes that fire from measured values and events (PV2, KPI variance, revenue concentration, dates, and logged events) act on the reading. Scorer agreement has not yet passed the reliability test. A proposal is confirmed at the next monthly governance review or the M13 Phase 3 review, whichever comes first, and a playbook's stated duration starts at confirmation. Routes that restore the M13 cadence itself act on the reading. A route that carries evidence feeds the next scoring of the receiving dimension and never sets a score directly. Module instruments are scored quarterly in weeks 11 to 12 of the M13 cycle, Module 1 in Phase 1, and measured signals at their own review cadence. An RT code names the destination action, so several source rows can share one.
Outbound routes
| Signal | Condition | Destination | What fires |
|---|---|---|---|
| Threat Model Currency | red | M12 PB-M12-01 | Threat Model and KPI Standup (RT-M12-THREAT-RED) |
| Data Classification Enforcement | red | M12 PB-M12-02 | Classification and PIA Activation (RT-M12-CLASSIFICATION-RED) |
| Data Classification Enforcement | red | M07 PB-M07-02 | M07 holds new deployments that touch unclassified data |
| Incident Response Readiness | red | M12 PB-M12-03 | Incident Runbook and Tabletop Program (RT-M12-INCIDENT-RED) |
| Incident Response Readiness | red | M10 PB-M10-01 | M10 runs security-awareness retraining for teams involved in human-factor incidents |
| Incident Response Readiness | red | M02 PB-M02-01 | Escalation matrix maintained as a coded SOP with 90-day review |
| PIA Gating | red | M12 PB-M12-02 | Classification and PIA Activation |
| PIA Gating | red | M09 PB-M09-03 | M09 marks privacy evidence stale in the diligence assembly |
| Security KPI Integration | red | M12 PB-M12-01 | Threat Model and KPI Standup |
| Security KPI Integration | red | M03 PB-M03-02 | Security KPIs configured on the M03 grid with named owners |
| PIA status signal | on event | M04 PB-M04-03 | Block go-live until PIA completes (RT-M04-CHANGE-CONTROL-RED) |
| MTTD security metric | red (M03 directional scale) | M03 PB-M03-03 | Variance Alert Engine routes MTTD red to the CISO and COO |
Dependencies, documented and not routed: M12 asset inventory reads the M04 System Inventory Sheet.
Inbound routes
| Signal | Condition | Source module | What fires in M12 |
|---|---|---|---|
| Data Hygiene | red in M01 | M01 | M12 compliance audit frequency doubles (PB-M12-04) |
| Compliance Baseline | red in M01 | M01 | Customer personal data defaults to Restricted tier, response windows compress from 72 to 24 hours (PB-M12-02) |
| Shadow IT Containment | red in M04 | M04 | M12 runs a discovery scan for tools in use without a completed PIA (PB-M12-02) |
| New-integration signal | on event in M04 | M04 | PIA before connect, CFO plus CISO signoff evidence (RT-M04-NEW-INTEGRATION-M12) (PB-M12-02) |
| Pipeline Stage Control | red in M07 | M07 | M12 audits PIA completion for every AI deployment at Stage 2 or later (PB-M12-02) |
| Dashboard and Privacy Tiering | red in M11 | M11 | M12 reclassifies people data to Confidential or Restricted and verifies dashboard access tiers (PB-M12-02) |
| Project Data Sensitivity score | >= 4 (grid score 1 to 5) in M07 | M07 | PIA scope flagged as high-sensitivity: Restricted-tier governance applies from Stage 2 (PB-M12-02) |
| AERI overall subscore | < 40 (AERI 0 to 100) in M01 | M01 | Automated threat detection keeps running. A person reviews every alert (PB-M12-01) |
Playbooks
Every playbook follows one lifecycle: open, running, met or missed, escalated, closed. A trigger that arrives while a playbook is open is logged against the open run. An outcome met, with an independent re-score at amber or better, closes the run, and the owner's next queued red opens. An outcome missed at the end of its stated duration escalates to the owner's manager and the next M13 quarter planning agenda. Someone other than the owner re-scores the dimension. Each owner runs at most three red playbooks at once. Further reds queue, ranked by how many modules the red dimension routes into. Safety playbooks (PB-M07-02, PB-M12-02, PB-M12-03) never queue. A red route opens a red playbook. A route that changes a mode, a cadence, or a data feed runs under the module's standing playbook. When a red playbook's outcome is met, any standing duty it set up continues under the standing playbook, which does not count toward the cap. Escalation for a CEO-owned playbook goes to the board.
PB-M12-01: Threat Model and KPI Standup (Threat / KPI)
Trigger: Threat Model Currency or Security KPI Integration red, assessment older than a quarter, or security metrics absent from the M03 dashboard. Also opened by routes from M01 AERI overall subscore. Builds the Threat Model Canvas on the five dimensions with the M04 System Inventory feeding asset inventory, and produces the prioritized risk register with owners and timelines. Sets the quarterly review plus real-time updates on new threat intelligence, then stands up the four KPI categories on the M03 grid with named owners and thresholds. Red MTTD routes to CISO and COO, with monthly reporting to both and quarterly reporting to the board. Outcome: canvas complete with register, KPIs live on the M03 dashboard with routing, review calendar and reporting cadence set. Owner: CISO with COO, 4 weeks.
PB-M12-02: Classification and PIA Activation (Classification / PIA)
Trigger: Data Classification Enforcement or PIA Gating red, unclassified data estates, or go-lives without PIAs. Also opened by routes from M01 Compliance Baseline, M04 New-integration signal, M04 Shadow IT Containment, M07 Pipeline Stage Control, M07 Project Data Sensitivity score, M11 Dashboard and Privacy Tiering. Publishes the four-tier classification matrix with handling rules and classifies the estate starting from the M04 inventory, customer personal data first. Turns on automated tagging at creation with an approval workflow for overrides, and wires the M01 compliance-baseline red escalation to Restricted default. Enforces PIA gating on all four trigger events, files completed PIAs audit-ready for M09, and confirms M07 pulls sensitivity scores from the matrix. Outcome: estate classified with auto-tagging live, AERI escalation demonstrated, PIA gate blocking verified on one real go-live, repository started. Owner: CISO with Data Protection lead, 5 weeks.
PB-M12-03: Incident Runbook and Tabletop Program (Readiness)
Trigger: Incident Response Readiness red, runbook missing or untested, or windows unknown to responders. Writes the three-tier runbook covering Tier 1 triage within the first hour, Tier 2 investigation and response through 24 hours, and Tier 3 recovery through 2 weeks. Sets the regulatory notification window at 72 hours standard and 24 hours on M01 compliance-baseline red, and publishes the escalation matrix as a coded M02 SOP. Runs the first quarterly tabletop per tier using the M10 framework and records results against Incident Response Readiness, with every gap logged into the runbook the same week. Outcome: runbook live with current windows, matrix coded in M02, first tabletop completed with lessons incorporated, results recorded in Incident Response Readiness. Owner: CISO with incident commander designate, 4 weeks.
PB-M12-04: Security Posture Monitoring (Amber Path)
Trigger: any M12 dimension amber, or green-state standing maintenance. Also opened by routes from M01 Data Hygiene. Reviews security KPIs monthly with the COO and investigates any two-month negative trend before it hits red. Confirms the quarterly threat model review, runs the quarterly tabletop, and audits PIA gating by sampling go-lives across M04 and M07. Checks classification health against the current M01 score, keeps the compliance repository diligence-ready for M09, and feeds posture trends to M13. Outcome: monthly and quarterly cycles kept, gating audit clean, repository current, M13 feed active. Owner: CISO, standing, with a 30-day pulse check for each amber dimension and green maintenance at the next M13 cycle.
Working templates ship with the module: the threat model canvas, the data classification matrix, and the incident runbook. Template artifacts and full playbook bodies are delivered during an engagement.