Evidence-Based Compliance: Why "Trust but Verify" Fails in Operational Technology

"Trust but verify" sounds reasonable until you realize verification happens once a year and trust is assumed for the other 364 days.

In operational technology—where a compromised PLC can shut down a power grid, contaminate water supplies, or cause industrial accidents—annual verification isn't good enough.

You need continuous, evidence-based validation that your security controls are working right now.

The Annual Audit Problem

Typical Compliance Cycle

Month 1 (January): Annual IEC 62443 audit scheduled

Months 2-10 (Feb-Oct): Business as usual

• Systems change
• Configurations drift
• Patches applied (or not)
• Employees come and go
• New threats emerge

Month 11 (November): Pre-audit scramble

• Fix obvious gaps
• Update documentation
• Refresh evidence
• "Clean up" before auditors arrive

Month 12 (December): Audit

• Auditors review evidence
• Findings issued
• Report states "compliant" or "non-compliant"

Result: You have a snapshot of security posture on one day (audit day), but zero visibility for the other 364 days.

What Goes Wrong Between Audits

Real incidents that happen in the 364-day gap:

1. Configuration Drift

   • Engineer disables MFA "temporarily" to troubleshoot (never re-enables it)
   • Firewall rule added for "urgent" production issue (bypasses DMZ)
   • Default credentials left on new HMI ("we'll fix it next week")

2. Personnel Changes

   • Key engineer leaves (takes security knowledge with them)
   • Contractor given admin access (never revoked after project ends)
   • Shared password used by departing employee (still works)

3. System Changes

   • New PLC added (not included in zone/conduit diagram)
   • SCADA server upgraded (breaks logging integration)
   • Network cable run directly from IT to OT ("just for this one time")

4. Threat Evolution

   • Zero-day vulnerability disclosed in OPC UA stack
   • Ransomware variant targets industrial PLCs
   • Nation-state APT publishes ICS-specific exploits

None of these are detected until the next audit—if at all.

What Is Evidence-Based Compliance?

Definition: Continuous validation of security controls through measurable evidence that is time-stamped, categorized by type, and tracked for freshness.

Core Principle: Compliance is not a state—it's a measurable confidence level that decays without fresh evidence.

The Four Types of Evidence

1. Intent Evidence

What it is: Documentation of what you plan to do.

Examples:

• Security policies
• Procedure documents
• Architecture diagrams
• Risk assessments

Value: Establishes baseline expectations but doesn't prove implementation.

Decay Rate: Slow (policies stable, valid ~1 year)

2. Implementation Evidence

What it is: Proof that controls are deployed.

Examples:

• Firewall rule exports
• Configuration backups
• Screenshot of access control settings
• Asset inventory snapshots

Value: Shows what's built but not whether it works or remains unchanged.

Decay Rate: Medium (configs can change, valid ~6 months)

3. Behavioral Evidence

What it is: Real-time operational data showing controls in action.

Examples:

• SIEM logs showing blocked traffic
• Authentication logs showing MFA usage
• IDS alerts on attack attempts
• Continuous network monitoring metrics

Value: Highest value—shows controls working right now. Can't be faked.

Decay Rate: Fast (recent data most relevant, valid ~3 months)

4. Validation Evidence

What it is: Independent third-party verification.

Examples:

• Penetration test reports
• IEC 62443 certification audits
• Vulnerability scan results
• External compliance assessments

Value: Most credible (independent, objective, hardest to game).

Decay Rate: Slow (annual audits typical, valid ~1 year)

Evidence Decay and Trust Scores

How Trust Decays

Evidence doesn't remain valid forever. Provn models evidence decay using exponential functions:

Trust Score = Σ (Evidence Weight × Quality × Age Factor)

Age Factor Formula:

Age Factor = e^(-λ × age_in_days)

Decay Rate Constants (λ):

• Intent Evidence: λ = 0.003 (slow decay)
• Implementation Evidence: λ = 0.005 (medium decay)
• Behavioral Evidence: λ = 0.008 (fast decay)
• Validation Evidence: λ = 0.002 (slowest decay)

Example: Trust Score Over Time

Requirement: "All privileged accounts use multi-factor authentication"

Evidence Collected:

Date	Evidence Type	Description	Quality	Trust Contribution
Jan 1	Intent	MFA Policy Document	0.8	0.48
Jan 15	Implementation	Okta MFA Config Screenshot	0.9	0.72
Jan 30	Behavioral	30 days of MFA usage logs	0.85	0.85
Feb 10	Validation	Pen test confirms MFA enforced	1.0	1.2

Initial Trust Score (Feb 10): 87/100 (High Confidence)

Trust Score Over Time:

Date	Age (Days)	Age Factors	Trust Score
Feb 10	Fresh	All 1.0	87/100 (High)
May 10 (90 days)	90	Behavioral: 0.72	82/100 (High)
Aug 10 (180 days)	180	Behavioral: 0.45, Implementation: 0.55	74/100 (Medium)
Nov 10 (270 days)	270	Behavioral: 0.25, Implementation: 0.35	62/100 (Medium-Low)

Without Fresh Evidence: Trust score decays from 87 → 62 over 9 months, even though MFA is still enforced!

With Continuous Behavioral Evidence: SIEM integration provides fresh MFA logs daily → Trust score stays at 85-87/100 continuously.

Continuous Evidence Collection

Automated Evidence Sources

1. SIEM Integration

• What it provides: Logs showing security events in real-time
• Evidence type: Behavioral
• Frequency: Continuous (daily/hourly uploads)
• Examples:
  • Blocked connection attempts
  • Failed authentication events
  • Firewall deny logs
  • IDS/IPS alerts

2. Asset Management Integrations

• What it provides: Current asset inventory state
• Evidence type: Implementation
• Frequency: Daily sync
• Examples:
  • ServiceNow CMDB integration
  • Fortigate firewall asset sync
  • Network scanner results (Claroty, Nozomi)

3. Configuration Management

• What it provides: Current configuration states
• Evidence type: Implementation
• Frequency: On-change or daily
• Examples:
  • Firewall rule exports
  • Active Directory user/group lists
  • PLC configuration backups

4. Monitoring Systems

• What it provides: System health and security metrics
• Evidence type: Behavioral
• Frequency: Real-time
• Examples:
  • OT network anomaly detection
  • Resource utilization metrics
  • Availability monitoring

5. Scheduled Assessments

• What it provides: Independent validation
• Evidence type: Validation
• Frequency: Quarterly/annually
• Examples:
  • Vulnerability scans
  • Penetration tests
  • Compliance audits

The Evidence Matrix

For each security requirement, map evidence across all four types:

Example: FR 5.2 (Zone Boundary Protection) at SL 3

Evidence Type	Artifact	Freshness	Trust Contribution	Next Refresh
Intent	Network Security Policy	90 days	Moderate	Annual review (270 days)
Implementation	Firewall Config Export	1 day	High	Daily automated export
Behavioral	Firewall Deny Logs (IT→OT blocked)	Today	Very High	Continuous (SIEM feed)
Validation	Pen Test: No IT→OT Path Confirmed	180 days	Moderate	Next test in 180 days

Composite Trust Score: 85/100 (High Confidence)

Decay Projection:

• At 270 days: Score drops to 78/100 (Medium-High)
• At 365 days: Score drops to 68/100 (Medium) without new validation evidence

Action: Schedule penetration test at 330 days to maintain high trust.

Real-World Example: Water Treatment Facility

Traditional Compliance Approach

Frequency: Annual IEC 62443 audit

Process:

1. Auditor reviews firewall rules once per year
2. Checks access control policies
3. Samples security logs
4. Issues report: "Compliant"

Incident (Month 7):

• Engineer adds temporary firewall rule: "Allow All from IT network to OT historian"
• Rule intended for 1-hour troubleshooting session
• Engineer forgets to remove rule
• IT ransomware spreads to OT network via open path
• Result: SCADA system encrypted, 48-hour production outage, $2M loss

Audit Detection: 5 months later (next annual audit)

Evidence-Based Compliance Approach

Frequency: Continuous evidence collection

Process:

1. Firewall rules exported daily (Implementation Evidence)
2. Firewall logs ingested hourly (Behavioral Evidence)
3. Trust score recalculated continuously

Same Incident (Month 7):

• Engineer adds temporary firewall rule
• 30 minutes later: Automated alert fires
  • "Trust score dropped: FR 5.2 (Zone Boundary Protection)"
  • "Reason: New firewall rule detected: Allow All IT→OT"
  • "Evidence gap: Rule contradicts network segmentation policy"
• Security team reviews alert
• Rule removed within 1 hour
• Result: Incident prevented, no production impact

Detection Time: 30 minutes (vs. 5 months)

Implementing Evidence-Based Compliance

Step 1: Map Requirements to Evidence Types

For each security requirement, identify:

• What Intent evidence is needed? (policies, standards)
• What Implementation evidence proves deployment? (configs, screenshots)
• What Behavioral evidence shows it working? (logs, metrics)
• What Validation evidence provides independent verification? (audits, pen tests)

Step 2: Automate Evidence Collection

High ROI Integrations:

1. SIEM Integration: Continuous behavioral evidence (logs, alerts)
2. CMDB Sync: Daily implementation evidence (asset inventory)
3. Firewall API: Daily configuration evidence (rule exports)
4. Vulnerability Scanner: Weekly validation evidence (scan results)

Step 3: Set Trust Score Thresholds

Define acceptable trust levels:

• Critical Requirements: Target ≥ 85 (High Confidence)
• High Priority: Target ≥ 80 (High Confidence)
• Medium Priority: Target ≥ 70 (Medium-High Confidence)
• All Others: Target ≥ 60 (Medium Confidence)

Step 4: Monitor and Alert

Configure alerts for:

• Trust score drops below threshold
• Evidence aging (no fresh evidence in X days)
• Evidence gaps (missing evidence types)
• Validation evidence expiring (pen test > 11 months old)

Step 5: Continuous Improvement

Use trust score trends to:

• Identify persistent evidence gaps
• Prioritize automation investments
• Demonstrate security posture improvements to leadership

The Executive Dashboard

Evidence-based compliance enables executive-level visibility through dashboards showing:

Organizational Trust Score: 82/100 (High) - Trending up +3 points over last 30 days

Evidence Health:

• ✅ Fresh (<30 days): 145 artifacts
• ⚠️ Aging (30-90 days): 38 artifacts
• 🔴 Stale (>90 days): 12 artifacts

Critical Gaps (Trust < 70):

• FR 6 (Monitoring): 68/100 - Missing SIEM logs
• FR 3 (Integrity): 65/100 - No integrity checks

Upcoming Evidence Expirations:

• Pen test expires in 60 days (re-test needed)
• ISO 27001 cert expires in 120 days

Value: Executives see security posture at a glance, understand gaps, and know what actions are needed.

Why This Matters for OT

Operational technology environments can't tolerate "compliance once a year":

1. Safety Critical: Failures can injure or kill people
2. Always On: 24/7 operations mean zero downtime tolerance
3. Long Lifecycles: Equipment lasts 20-30 years; can't "reboot to apply patches"
4. Regulatory Pressure: NERC CIP, IEC 62443, NIS Directive require continuous validation
5. Increasing Threats: IT/OT convergence brings IT threats to OT environments

Evidence-based compliance shifts from:

• Reactive (find problems in annual audits) → Proactive (detect issues within hours/days)
• Point-in-time (audit day snapshot) → Continuous (real-time confidence)
• Binary (compliant/non-compliant) → Nuanced (confidence levels and trends)

---

Ready to move from annual audits to continuous, evidence-based validation? Request a demo to see how Provn tracks trust scores in real-time for operational technology environments.