Data Protection Controls

The C2M2 Architecture-1.C requirement mandates that organizations implement controls to protect data at rest and in transit. This goes beyond basic encryption to encompass a comprehensive data protection program including access controls, data loss prevention, and documented evidence of implementation.

For energy sector organizations and critical infrastructure operators, this requirement forms the foundation of cybersecurity maturity. Data breaches in critical infrastructure can impact national security and public safety, making robust data protection controls essential rather than optional.

The requirement explicitly calls for controls protecting data in two states: at rest (stored data) and in transit (data moving across networks). However, mature implementations also consider data during processing, in backup systems, and during disposal. Your audit success depends on demonstrating comprehensive protection across all data lifecycles, not just checking encryption boxes.

Regulatory text

The C2M2 v2.1 ARCHITECTURE-1.C requirement states: "Controls are implemented to protect data at rest and in transit."

This requirement mandates technical and administrative controls that ensure data confidentiality and integrity whether stored on systems or transmitted across networks. The regulation intentionally uses broad language to accommodate various implementation approaches while maintaining clear protection objectives.

Who This Applies To

This requirement applies to:

• Energy sector organizations implementing C2M2
• Critical infrastructure operators seeking cybersecurity maturity
• Third-party service providers handling energy sector data
• Cloud providers storing or processing critical infrastructure information
• Managed service providers with access to operational technology networks

The requirement scales with organizational maturity levels. MIL2 implementations focus on documented controls for critical systems, while higher maturity levels demand comprehensive protection across all data categories.

Step-by-Step Implementation Guide

Phase 1: Data Discovery and Classification (Days 1-30)

1. Inventory all data repositories

   • Document databases, file shares, cloud storage, backup systems
   • Map data flows between systems
   • Identify data owners and custodians

2. Classify data by sensitivity

   • Critical operational data (SCADA, control systems)
   • Business confidential information
   • Personal data subject to privacy regulations
   • Public or non-sensitive data

3. Document current protection measures

   • Existing encryption implementations
   • Access control mechanisms
   • Data loss prevention tools
   • Backup and recovery procedures

Phase 2: Gap Analysis and Control Design (Days 31-45)

4. Assess protection gaps

   • Unencrypted data stores
   • Clear-text transmission protocols
   • Weak access controls
   • Missing data loss prevention

5. Design control implementation

   • Select encryption standards (AES-256 for data at rest, TLS 1.2+ for transit)
   • Define access control requirements
   • Plan data loss prevention deployment
   • Document key management procedures

Phase 3: Control Implementation (Days 46-75)

6. Deploy data-at-rest protection

   • Enable full-disk encryption on endpoints
   • Implement database encryption
   • Encrypt backup media
   • Secure cloud storage buckets

7. Implement data-in-transit controls

   • Deploy TLS/SSL for all web traffic
   • Implement VPN for remote access
   • Encrypt email communications
   • Secure API connections

8. Configure access controls

   • Implement role-based access
   • Deploy multi-factor authentication
   • Configure privileged access management
   • Enable audit logging

Phase 4: Documentation and Testing (Days 76-90)

9. Document implementation evidence

   • Technical configuration guides
   • Encryption certificate details
   • Access control matrices
   • Data flow diagrams with protection points

10. Validate control effectiveness

    • Penetration testing for encryption bypass
    • Access control testing
    • Data loss prevention testing
    • Incident response drills

Required Evidence and Artifacts

Maintain these documents for audit readiness:

1. Data Protection Policy - Formal policy covering encryption standards, access controls, and data handling procedures
2. Technical Implementation Guides - Step-by-step procedures for enabling encryption and access controls
3. Data Flow Diagrams - Visual representation showing protection points for data in motion
4. Encryption Inventory - Spreadsheet listing all systems, encryption methods, and key management details
5. Access Control Matrix - Documentation of who can access what data and under which conditions
6. Testing Reports - Results from penetration tests, vulnerability assessments, and control validation
7. Key Management Procedures - Documentation of encryption key generation, storage, rotation, and recovery
8. Incident Response Plan - Procedures for responding to data protection failures

Common Audit Questions and Preparation

Auditors typically focus on these areas:

"Show me your encryption standards"

• Have documented standards specifying minimum encryption strengths
• Include both algorithm requirements (AES-256) and implementation details
• Document any approved exceptions with compensating controls

"How do you protect data during processing?"

• Document application-level controls
• Show memory protection mechanisms
• Demonstrate secure coding practices

"What about legacy systems that can't support encryption?"

• Document all exceptions with risk assessments
• Show compensating controls (network segmentation, increased monitoring)
• Include migration plans to eliminate exceptions

"How do you manage encryption keys?"

• Demonstrate key lifecycle management
• Show separation of keys from encrypted data
• Document key recovery procedures

Implementation Mistakes to Avoid

Mistake 1: Encryption Without Key Management

Organizations often enable encryption but store keys alongside encrypted data. Implement proper key management with hardware security modules or dedicated key management services.

Mistake 2: Ignoring Data in Use

The requirement mentions data at rest and in transit, but modern attacks target data during processing. Implement application-level controls and secure enclaves for sensitive processing.

Mistake 3: Inconsistent Implementation

Protecting a meaningful percentage of data leaves exploitable gaps. Document all data locations and ensure consistent protection. One unencrypted backup defeats your entire program.

Mistake 4: Weak Access Controls

Encryption means nothing if everyone has access. Implement principle of least privilege, regular access reviews, and automated de-provisioning.

Mistake 5: Missing Evidence

Technical controls without documentation fail audits. Maintain configuration screenshots, test results, and implementation records from day one.

30/60/90-Day Execution Plan

Immediate Actions (Days 1-30)

• Complete data inventory and classification
• Document existing controls
• Identify critical gaps requiring immediate attention
• Enable encryption on most critical systems
• Establish project governance and assign responsibilities

Near-term Implementation (Days 31-60)

• Deploy encryption for all data at rest
• Implement secure transmission protocols
• Configure access controls and authentication
• Begin documentation of technical controls
• Conduct initial testing of implemented controls

Ongoing Maturity (Days 61-90)

• Complete comprehensive documentation
• Perform full control validation testing
• Address any identified gaps
• Train staff on procedures
• Establish continuous monitoring and improvement processes

Frequently Asked Questions

Does "data in transit" include internal network traffic, or just internet-facing connections?

Data in transit includes all network transmissions where data moves between systems, including internal networks. While internet-facing connections require stronger controls, internal clear-text protocols like Telnet or unencrypted database connections also violate this requirement.

How do we handle legacy industrial control systems that don't support modern encryption?

Document these systems as exceptions with formal risk assessments. Implement compensating controls such as network segmentation, increased monitoring, and physical security. Create a modernization roadmap showing planned upgrades or replacements.

What encryption strength satisfies the requirement?

While C2M2 doesn't specify algorithms, industry standard is AES-256 for data at rest and TLS 1.2 or higher for data in transit. Document your chosen standards and ensure they align with current NIST recommendations.

Do backup tapes need encryption if they're stored in a secure facility?

Yes, physical security alone doesn't satisfy the data-at-rest protection requirement. Encrypt backup media, especially tapes that leave your facility for offsite storage. Physical security supplements but doesn't replace encryption.

How do we prove data protection controls are "implemented" versus just configured?

Show three types of evidence: configuration documentation proving controls exist, testing results demonstrating they work as designed, and operational metrics showing ongoing effectiveness. Screenshots of enabled encryption satisfy configuration, but penetration test results prove implementation.

What about data destruction and disposal?

While the requirement focuses on active data protection, complete implementations include secure disposal. Document data sanitization procedures for decommissioned hardware and expired backups. This prevents data breaches through improper disposal.