📋 Policy Implementation Tracking Model¶

The Core Distinction¶

GetCimple makes a critical distinction that most governance platforms miss:

A policy is a governance standard (what you SHALL do), not a statement of current reality (what you currently ARE doing).

This separation between policy and implementation is fundamental to honest, effective governance.

The Problem This Solves¶

Traditional Approach (Broken)¶

Most compliance tools treat policies as binary:

✅ Policy exists → You're compliant
❌ Policy doesn't exist → You're non-compliant

This creates a dangerous illusion where having a policy document means you're "doing" what it says.

GetCimple's Approach (Honest)¶

We separate three distinct states:

Policy Status: Is the policy approved as your governance standard?
Implementation Status: Are you actually doing what the policy requires?
Gap Status: What's the difference between what you said you'd do and what you're actually doing?

Real-World Example: SDLC Policy¶

Scenario: Software Development Company¶

A company develops custom web and mobile applications. They adopt the Secure Software Development Lifecycle (SDLC) Policy during onboarding.

During Assessment, They Reveal:¶

✅ Implemented (20% of requirements):

Using Git for version control
Some code review happening
Basic deployment process

⚠️ Partially Implemented (30% of requirements):

Have dev and prod environments (but staging is mixed with dev)
Some input validation (but inconsistent)
API authentication on some APIs (but not all)

❌ Not Implemented (50% of requirements):

No SAST/DAST/SCA testing
No vulnerability disclosure program
No Software Bill of Materials (SBOM)
No threat modeling
No security training for developers
No formal secure coding standards
No secrets scanning

What Happens Next?¶

1. Policy Status: APPROVED ✅¶

The board approves the SDLC policy as the company's security standard for software development.

This means: "We commit that this is what we SHOULD be doing."

2. Implementation Status: 23% COMPLIANT ⚠️¶

The system calculates actual compliance:

Implemented controls: 20%
Partially implemented: 30% × 0.1 weighting = 3%
Total: 23% compliant

This means: "This is what we're ACTUALLY doing today."

3. Gap Analysis Generated 📊¶

Critical Gaps (5 items):

No SAST/DAST/SCA testing (ISM-0402) - High Risk
No vulnerability disclosure program (ISM-1616) - High Risk
No SBOM generation (ISM-1730) - Medium Risk
No threat modeling (ISM-1238) - Medium Risk
No secrets scanning (ISM-2030) - High Risk

Medium Priority Gaps (8 items):

Incomplete environment segregation
Inconsistent input validation
Partial API authentication
etc.

4. Remediation Roadmap Created 🎯¶

Each gap gets:

Owner: CTO, Security Lead, Dev Lead
Target Date: Based on priority and resources
Priority: Critical, High, Medium, Low
Resources Required: Tools, training, time

Example Roadmap:

Q1 2025: Implement SAST/DAST/SCA tools (Owner: CTO, Budget: $15K)
Q2 2025: Launch vulnerability disclosure program (Owner: Security Lead)
Q2 2025: Implement SBOM generation (Owner: Dev Lead)
Q3 2025: Formalize secure coding standards (Owner: Dev Lead)
Q4 2025: Complete environment segregation (Owner: CTO)

5. Board Approval Package 📋¶

The board approves THREE things:

✅ The Policy: "This is our security standard"
✅ The Gap Analysis: "We acknowledge we're only 23% compliant"
✅ The Remediation Plan: "Here's how we'll reach 80% by EOY"

How It Appears in GetCimple¶

Policy Dashboard¶

┌─────────────────────────────────────────────────────────┐
│ Secure Software Development Lifecycle Policy            │
├─────────────────────────────────────────────────────────┤
│ Status: ACTIVE ✅                                       │
│ Approval Date: 2025-01-15                              │
│ Approved By: Board of Directors                         │
│                                                          │
│ Implementation: 23% ⚠️                                  │
│ Target: 80% by 2025-12-31 🎯                           │
│                                                          │
│ Controls Tracked: 52                                    │
│ ├─ Implemented: 10 (19%)                               │
│ ├─ In Progress: 16 (31%)                               │
│ ├─ Not Started: 24 (46%)                               │
│ └─ Not Applicable: 2 (4%)                              │
│                                                          │
│ Next Board Review: 2025-04-15                           │
└─────────────────────────────────────────────────────────┘

Board Report (Quarterly)¶

SDLC POLICY COMPLIANCE REPORT - Q1 2025

Policy Status: Active ✅
Overall Implementation: 23% ⚠️
Target for Q2: 45% 🎯
On Track: Yes ✅

CRITICAL GAPS REQUIRING BOARD ATTENTION:

1. No SAST/DAST/SCA Testing
   - Risk: High - Vulnerable code may reach production
   - Owner: CTO
   - Status: Tool evaluation in progress
   - Target: 2025-03-31
   - Budget: $15K approved

2. No Vulnerability Disclosure Program
   - Risk: High - No mechanism for security researchers
   - Owner: Security Lead
   - Status: Policy draft under review
   - Target: 2025-04-30
   - Budget: No additional cost

PROGRESS SINCE LAST QUARTER:

✅ Completed:
- Git version control standardized
- Code review process formalized

🟡 In Progress (8 items):
- SAST/DAST/SCA implementation (40% complete)
- Environment segregation (staging environment deployed)
- API authentication rollout (60% of APIs secured)

📊 Compliance Trend:
Q4 2024: 18%
Q1 2025: 23% (+5%)
Q2 2025: 45% (target)

Control-Level Detail View¶

POLICY: Secure Software Development Lifecycle
SECTION: 2.1 Software Artefact Security

Control: ISM-2026 - Scan artefacts for malicious code
├─ Status: NOT IMPLEMENTED ❌
├─ Risk: HIGH 🔴
├─ Owner: CTO
├─ Target Date: 2025-03-31
├─ Evidence Required:
│   └─ Screenshots of scanning tool
│   └─ Sample scan reports
│   └─ CI/CD pipeline configuration
└─ Remediation Notes:
    └─ Evaluating Snyk vs. WhiteSource
    └─ Budget approved: $15K
    └─ Integration with GitHub Actions planned

Control: ISM-2027 - Verify artefacts by digital signature
├─ Status: NOT IMPLEMENTED ❌
├─ Risk: HIGH 🔴
├─ Owner: DevOps Lead
├─ Target Date: 2025-04-15
└─ Dependencies: ISM-2026 must be completed first

Control: ISM-2023 - Authoritative source for software
├─ Status: IMPLEMENTED ✅
├─ Implementation Date: 2024-06-15
├─ Evidence:
│   └─ GitHub Enterprise instance
│   └─ Access control policies
│   └─ Audit logs
└─ Review Date: 2025-06-15

The Three-State Model¶

1. Policy State (Governance)¶

Question: "What have we committed to do?"

Possible Values:

Draft: Policy being developed
Under Review: Policy awaiting board approval
Approved: Board has approved as standard
Active: Policy in force
Superseded: Replaced by newer version

Board's Role: Approve or reject the policy as the organization's standard.

2. Implementation State (Reality)¶

Question: "What are we actually doing?"

Measured At: Control level (not policy level for complex policies)

Possible Values Per Control:

Not Started: No implementation yet
In Progress: Partially implemented
Implemented: Fully implemented
Not Applicable: Control doesn't apply to this organization

Management's Role: Update implementation status as work progresses, upload evidence.

3. Gap State (Action Required)¶

Question: "What's the difference between what we said and what we're doing?"

Calculated Automatically:

Gap Size: Implementation percentage vs. target
Risk Level: Based on ACSC ISM criticality ratings
Priority: Critical, High, Medium, Low
Timeline: Target completion dates
Resources: Budget and people required

Everyone's Role:

Board: Oversees gap closure progress
Management: Executes remediation plan
Implementation Team: Does the actual work

Why This Matters¶

For Directors¶

Honest Oversight: See the real picture, not a fantasy.

"We have a policy" ≠ "We're compliant"

Directors can see:

What standard has been set (the policy)
What's actually happening (implementation status)
What work is needed (the gap)
Who's responsible and when (remediation plan)
Progress over time (quarterly tracking)

Legal Protection: Demonstrates active oversight and good governance, even when gaps exist.

For Management¶

Clear Roadmap: Know exactly what to implement and when.

No more guessing:

✅ Specific controls to implement
✅ Clear priorities
✅ Assigned owners
✅ Target dates
✅ Success criteria

Progress Visibility: Show the board you're making progress.

For Auditors¶

Transparency: Demonstrates mature governance.

Auditors see:

Policies exist (governance framework)
Gaps are identified (self-awareness)
Plans exist to close gaps (commitment)
Progress is tracked (accountability)

This is better than pretending everything is perfect.

Policy Types: Simple vs. Complex¶

Simple Policies¶

Characteristics:

10-15 requirements
Usually high implementation rates
Can report at policy level

Examples:

Password Policy
Acceptable Use Policy
Social Media Policy

Reporting: "Password Policy: 90% compliant"

Complex Policies¶

Characteristics:

50+ requirements
Often low initial implementation
MUST report at control level

Examples:

Secure Software Development Lifecycle Policy (52 controls)
Infrastructure, Network and Cloud Security Policy
Vulnerability Management Policy

Reporting: Requires detailed control-level tracking with remediation roadmap.

Common Scenarios¶

Scenario 1: New Policy, Low Implementation¶

Example: Adopting SDLC policy when no secure development practices exist.

Result:

Policy: Active ✅
Implementation: 15% ⚠️
Gap: 85% 🔴

Board Action: Approve aggressive remediation timeline with budget.

Scenario 2: Existing Practices, Formalizing Policy¶

Example: Company already does secure coding but never formalized it.

Result:

Policy: Active ✅
Implementation: 70% ✅
Gap: 30% 🟡

Board Action: Quick approval, focus on documenting existing practices.

Scenario 3: Progressive Implementation¶

Example: Taking 18 months to reach full compliance.

Progress:

Q1: 23% → Q2: 45% → Q3: 62% → Q4: 80% ✅

Board Action: Quarterly reviews to track progress and adjust as needed.

Scenario 4: Risk Acceptance¶

Example: Some controls are too expensive or not applicable.

Result:

Policy: Active ✅
Implementation: 65% ✅
Gap: 35% (20% accepted risk, 15% planned)

Board Action: Formally accept certain risks, commit to closing other gaps.

Data Model Overview¶

Policy
├─ policy_id: UUID
├─ policy_name: "Secure Software Development Lifecycle Policy"
├─ policy_status: "Active"
├─ approval_date: "2025-01-15"
├─ approval_authority: "Board of Directors"
├─ overall_compliance: 23% (calculated)
├─ target_compliance: 80%
├─ target_date: "2025-12-31"
└─ controls: Control[]

Control
├─ control_id: UUID
├─ control_reference: "ISM-2026"
├─ control_description: "Scan all artefacts for malicious code"
├─ control_requirement: "All software artefacts scanned before import"
├─ section: "2.1 Software Artefact Security"
├─ implementation_status: "Not Started" | "In Progress" | "Implemented" | "N/A"
├─ implementation_percentage: 0-100%
├─ risk_level: "Critical" | "High" | "Medium" | "Low"
├─ assigned_owner: "CTO"
├─ target_implementation_date: "2025-03-31"
├─ actual_implementation_date: null
├─ evidence_required: string[]
├─ evidence_uploaded: Evidence[]
└─ remediation_notes: "Evaluating Snyk vs. WhiteSource"

Evidence
├─ evidence_id: UUID
├─ control_id: UUID
├─ evidence_type: "Screenshot" | "Document" | "Configuration" | "Log"
├─ file_url: string
├─ uploaded_by: User
├─ upload_date: timestamp
└─ description: string

Integration with Essential Eight¶

Essential Eight already uses this model successfully:

E8 Status: Maturity level (0, 1, 2, 3)
Implementation: Current maturity vs. Target maturity
Gap: Controls below target maturity
Remediation: Roadmap to target maturity

GetCimple extends this proven approach to all policies.

Best Practices¶

For Onboarding¶

Be Honest: Don't inflate implementation status
Start Small: Pick achievable targets for first quarter
Show Progress: Even 5% improvement matters
Document Everything: Evidence is key

For Board Reporting¶

Lead with Status: Policy active, implementation at X%
Show Trend: Progress since last quarter
Highlight Wins: Completed controls
Focus on Gaps: What needs attention
Clear Accountability: Who owns what

For Implementation Teams¶

Update Regularly: Keep status current
Upload Evidence: As soon as controls are implemented
Flag Blockers: If stuck, escalate early
Celebrate Progress: Mark controls complete

Key Takeaways¶

Policies are standards, not statements of current reality
Implementation is tracked separately at the control level
Gaps are identified and managed with clear ownership
Board approves three things: Policy + Gap Analysis + Remediation Plan
Progress is tracked over time with quarterly board reviews
Honesty is valued over the illusion of perfect compliance

📋 Policy Implementation Tracking Model¶

The Core Distinction¶

The Problem This Solves¶

Traditional Approach (Broken)¶

GetCimple's Approach (Honest)¶

Real-World Example: SDLC Policy¶

Scenario: Software Development Company¶

During Assessment, They Reveal:¶

What Happens Next?¶

1. Policy Status: APPROVED ✅¶

2. Implementation Status: 23% COMPLIANT ⚠️¶

3. Gap Analysis Generated 📊¶

4. Remediation Roadmap Created 🎯¶

5. Board Approval Package 📋¶

How It Appears in GetCimple¶

Policy Dashboard¶

Board Report (Quarterly)¶

Control-Level Detail View¶

The Three-State Model¶

1. Policy State (Governance)¶

2. Implementation State (Reality)¶

3. Gap State (Action Required)¶

Why This Matters¶

For Directors¶

For Management¶

For Auditors¶

Policy Types: Simple vs. Complex¶

Simple Policies¶

Complex Policies¶

Common Scenarios¶

Scenario 1: New Policy, Low Implementation¶

Scenario 2: Existing Practices, Formalizing Policy¶

Scenario 3: Progressive Implementation¶

Scenario 4: Risk Acceptance¶

Data Model Overview¶

Integration with Essential Eight¶

Best Practices¶

For Onboarding¶

For Board Reporting¶

For Implementation Teams¶

Key Takeaways¶

Further Reading¶