A.8.9 and A.8.10 — Configuration Management and Data Deletion
The Gap Between Policy and Practice
Configuration management and data deletion are two controls that most organizations claim to have handled, yet when I ask for evidence during audits, the room goes quiet. These aren't glamorous controls. Nobody's building a startup around configuration management. But Control 8.9 (Configuration Management) and Control 8.10 (Information Deletion) sit at the intersection of operational security and legal compliance, and getting them wrong can sink your certification audit faster than a missing risk assessment.
I've seen organizations with multi-million dollar security budgets that couldn't tell me the approved configuration baseline for their production web servers. I've watched data protection officers squirm when asked to demonstrate that personal data was actually deleted after retention periods expired. These controls expose the gap between documented policy and operational reality—and that gap is where auditors spend most of our time.
Understanding Control 8.9 — Configuration Management
Control 8.9 requires that configurations, including security configurations, of hardware, software, services, and networks should be established, documented, implemented, monitored, and reviewed. That's five distinct verbs, and each one represents a potential audit finding if not properly addressed.
This isn't just having a spreadsheet somewhere that lists your servers. The 2022 standard emphasizes that configuration management must be a living process that maintains documented baselines defining the approved state of systems, implements mechanisms to detect drift from those baselines, and establishes processes to review and update configurations as threats evolve.
Standard Templates: The Foundation You're Missing
The updated guidance specifically requires standard templates for secure configuration. These templates should be based on publicly available guidance—think CIS benchmarks, NIST guidelines, or vendor hardening guides—but adapted to your organization's context and risk appetite.
Most organizations I audit have some form of configuration documentation, but it's typically stale. They created it during initial deployment, maybe updated it once or twice, and then forgot about it. When I ask to see the current approved baseline for their Windows Server fleet, they show me a document from 2019 that references Windows Server 2016 configurations—while they're actually running 2022 in production.
A proper configuration baseline should include:
- Operating system hardening settings with specific registry keys, service states, and security policies
- Application-specific security configurations with version numbers and approved parameters
- Network device configurations including firewall rules, router ACLs, and switch port security
- Cloud resource configurations covering security groups, IAM policies, and storage bucket permissions
- Container and orchestration platform settings for Kubernetes, Docker, or similar technologies
Each baseline needs metadata: version number, approval date, designated owner, and scheduled review intervals. Without these elements, your baseline is just documentation theater.
Configuration Monitoring: Where Most Implementations Fail
Here's where the rubber meets the road. The 2022 standard explicitly requires monitoring configurations with comprehensive system management tools. I audited a healthcare organization last year that had beautiful, CIS-benchmark-aligned configuration standards. The problem? Their actual production systems had drifted so far from baseline that only 23% of their Windows servers would have passed a compliance scan. They had no idea until we ran one during the audit.
Effective configuration monitoring requires automated tools—whether commercial solutions like Rapid7, Qualys VMDR, or Tenable, open-source options like OSSEC or Wazuh, or cloud-native services like AWS Config, Azure Policy, or Google Cloud Security Command Center. Manual spot-checks don't satisfy the control's monitoring requirement.
The standard notes that actual configurations should be compared with defined target templates, and any deviations must be addressed either through automatic enforcement or manual analysis followed by corrective actions. This means your monitoring system needs to not just detect drift but trigger remediation workflows.
Security Configuration Essentials
Control 8.9 specifically calls out security configurations, which in practice means paying particular attention to:
- Default credentials that haven't been changed (still the #1 finding in my network device audits)
- Unnecessary services and ports that remain enabled
- Overly permissive access controls and file system permissions
- Missing security patches (which creates overlap with Control 8.8 on vulnerability management)
- Weak cryptographic configurations including deprecated TLS versions and cipher suites
- Logging configurations that don't capture security-relevant events for Control 8.16 monitoring
I find the most common failures in network device configurations. Routers and switches are often deployed with vendor defaults and never hardened because "they're internal" or "the network team handles that separately." ISO 27001 doesn't care about your organizational silos—the control applies to all configurations within your ISMS scope.
Auditor Tip: Configuration templates and targets contain sensitive security information and should be protected from unauthorized access. I've seen organizations inadvertently expose their security posture by storing configuration baselines in shared drives accessible to all employees.
Understanding Control 8.10 — Information Deletion
Control 8.10 requires that information stored in information systems, devices, or any other storage media should be deleted when no longer required. This sounds straightforward until you start asking uncomfortable questions about implementation.
This control exists because data that shouldn't exist can't be breached. Every gigabyte of retained data beyond your legal or business requirements represents unnecessary exposure. The 2022 update strengthens the deletion requirements and emphasizes the need for secure deletion methods that prevent data recovery.
The Business Justification Problem
Most organizations struggle with the fundamental question: "How do you know when information is no longer required?" This requires clear data retention policies that specify retention periods for different categories of information, but more importantly, it requires business processes that actually act on those policies.
I audited a professional services firm that had a three-year retention policy for client project files. Sounds reasonable. The problem? Their file servers contained client data going back to 1998, including sensitive financial information for companies that no longer existed. When I asked how they determined when data was no longer required, the silence was deafening.
Effective information deletion requires:
- Clear data retention schedules tied to business, legal, and regulatory requirements
- Automated deletion processes that execute based on those schedules
- Manual deletion procedures for ad-hoc requests (like GDPR erasure requests)
- Logging and evidence collection to prove deletion occurred
- Coordination with third-party service providers who process data on your behalf
Deletion Methods: Beyond the Recycle Bin
The updated guidance provides specific direction on deletion methods. Simply pressing delete or emptying the recycle bin doesn't satisfy the control. The standard requires selecting deletion methods based on business requirements and considering relevant laws and regulations.
For electronic data, this typically means:
- Cryptographic erasure for encrypted storage (destroy the keys, render data unrecoverable)
- Secure overwriting using approved tools that meet standards like NIST 800-88
- Physical destruction for highly sensitive data or when other methods aren't feasible
For cloud services, the challenge multiplies. You need to verify that your cloud service provider's deletion methods are acceptable. This is where standards like ISO 27017 (cloud security controls) become relevant. Cloud providers often use cryptographic erasure, but you need documented evidence that deletion occurred according to your requirements.
Third-Party Deletion Challenges
The 2022 update emphasizes that when third parties store your information, you must include deletion requirements in your agreements. This ties directly to Control 5.19 (Information Security in Supplier Relationships) and potentially ISO 27036 series on supplier relationship security.
I've seen organizations assume that canceling a SaaS subscription automatically deletes their data. Wrong. Most cloud providers retain data for varying periods after service termination. You need explicit deletion clauses in your contracts and documented evidence that deletion occurred.
What Auditors Look For
During configuration management audits, I examine:
- Configuration baselines: Current, approved, and version-controlled templates
- Monitoring evidence: Reports showing configuration compliance rates and drift detection
- Change management integration: Evidence that configuration changes follow Control 8.32 processes
- Remediation tracking: How deviations are identified, prioritized, and resolved
- Review records: Periodic reviews of baselines to address new threats or system changes
For information deletion audits, I look for:
- Retention policies: Clear, business-justified retention schedules for different data types
- Deletion logs: Automated and manual deletion activities with timestamps and responsible parties
- Method documentation: Evidence that appropriate secure deletion methods are used
- Third-party agreements: Deletion clauses in supplier contracts and evidence of execution
- GDPR compliance: For EU-relevant data, response procedures for erasure requests under ISO 27555 guidance
Common Audit Finding: Organizations often have excellent deletion policies but lack the operational processes to execute them. I regularly find data that should have been deleted months or years ago, still sitting in production systems because nobody took responsibility for actually performing the deletion.
Integration with Related Controls
Configuration management and information deletion don't exist in isolation. They integrate with multiple other controls:
- Control 5.9 (Inventory of Information and Assets): You can't manage configurations for assets you don't know about
- Control 8.8 (Management of Technical Vulnerabilities): Configuration baselines should include current patch levels
- Control 8.16 (Monitoring Activities): Configuration changes and deletion activities should be logged and monitored
- Control 8.32 (Change Management): All configuration changes must follow established change procedures
For organizations handling personal data, ISO 27018 provides additional guidance on PII protection in cloud environments, while ISO 27555 offers specific direction on PII deletion requirements that complement Control 8.10.
Making It Work in Practice
Start with your current state. Most organizations already have some configuration management and data handling processes—they're just not formalized or consistently applied. Map your existing practices against the control requirements to identify gaps.
For configuration management, begin by identifying critical systems and establishing baselines for those first. You don't need to baseline every workstation on day one. Focus on servers, network devices, and systems that handle sensitive data.
For information deletion, start with a data inventory exercise. You can't delete what you don't know you have. Identify where sensitive data resides, establish retention requirements for each category, and then implement deletion procedures.
Remember that both controls emphasize automation where possible. Manual processes don't scale and are prone to human error. Invest in tools that can monitor configurations and automate deletion workflows based on your policies.
These controls might not be glamorous, but they're fundamental to operational security. Get them right, and your audit will focus on more strategic security discussions. Get them wrong, and you'll be explaining why you can't demonstrate basic information security hygiene.
---Need help implementing configuration management or information deletion controls? Join the discussion with other ISO 27001 practitioners at the IX ISO 27001 Info Hub or book a consultation to review your current implementation approach.
Need personalized guidance? Reach our team at ix@isegrim-x.com.
Related Articles
- A.8.1 through A.8.5 — Endpoint Devices Access Rights and Authentication
- A.8.6 through A.8.8 — Capacity Malware and Vulnerability Management
- A.8.11 and A.8.12 — Data Masking and Data Leakage Prevention
- Annex A.5.1 through A.5.4 — Information Security Policies and Roles
- A.7.1 through A.7.4 — Physical Perimeters Entry and Securing Facilities