Annex A Controls

A.8.6 through A.8.8 — Capacity Malware and Vulnerability Management

Alex Fuerst

14 Oct 2025 — 6 min read

A.8.6 Capacity Management: The Foundation That Prevents Security Tool Failure

Control 8.6 requires that resource usage be monitored, adjusted, and projected to ensure required system performance. As lead auditor, I've watched organizations spend hundreds of thousands on security tools only to see them fail during critical moments because nobody considered capacity management a security issue.

I recently audited a mid-sized financial services firm that had invested heavily in their security stack—SIEM, EDR, vulnerability scanners, backup systems. Their security team was proud of their comprehensive toolset. During my review, I asked to see capacity monitoring for these security systems. The CISO looked puzzled. "That's infrastructure's responsibility," he said. Two weeks after my audit, their SIEM lost eight hours of critical logs during a suspected breach because storage hit 100% capacity and the log ingestion service crashed.

The control explicitly connects capacity to "required system performance." For security systems, this isn't about dashboard responsiveness—it's about:

SIEM ingestion rates matching actual log volumes without dropping events during peak periods or incidents
Vulnerability scanners completing full environment scans within defined maintenance windows
Malware analysis sandboxes processing submitted samples within acceptable timeframes for incident response
Backup systems completing within backup windows so recovery points actually exist when needed
EDR agents maintaining real-time monitoring without degrading endpoint performance

Practical implementation means establishing baseline resource utilization for every security system, not just primary business applications. Set alerting at 70% for warnings and 85% for critical thresholds. Build capacity projections that account for log volume growth, endpoint additions, and attack scenario load increases. If you're adding 50 endpoints monthly and your EDR licensing caps out in four months, that's a capacity planning failure waiting to create security gaps.

Document your capacity management process within your ISMS per Control 5.1 (Policies for information security). Include monitoring responsibilities, review frequencies, expansion triggers, and emergency capacity procedures. Cross-reference with Control 8.9 (Configuration management) to ensure capacity changes follow change control processes.

A.8.7 Protection Against Malware: Beyond Windows Endpoints

Control 8.7 mandates malware protection implementation supported by appropriate user awareness. The scope extends far beyond traditional antivirus on Windows machines, yet most organizations I audit treat it as exactly that—a checkbox exercise in endpoint agent deployment.

I've audited countless organizations where malware protection consists of:

Commercial antivirus on Windows workstations and servers
Nothing on Linux systems because "Linux doesn't get viruses"
No protection for network appliances, storage arrays, or IoT devices
Basic spam filtering without attachment analysis
No web content filtering or proxy inspection
Unrestricted removable media usage

The Linux mythology particularly concerns me. I watched a DevOps team confidently explain that their production Linux servers needed no malware protection due to "inherent architectural security." These systems ran containers pulled from public registries without image scanning, processed user file uploads without inspection, and executed scheduled scripts downloaded from external repositories. The attack surface was enormous, masked by outdated assumptions.

Effective malware protection under this control requires layered defense across all systems capable of executing code:

Email security with attachment sandboxing and URL analysis, not just spam scoring
Web filtering that inspects encrypted traffic through TLS inspection or endpoint DNS filtering
Network-based malware detection monitoring east-west traffic, not just perimeter ingress
Container image scanning in CI/CD pipelines before deployment to production
File upload inspection for web applications processing user content
Removable media controls including encryption requirements and usage logging
DNS filtering to block known malicious domains and detect DNS tunneling

User awareness, explicitly mentioned in the control, must cover social engineering tactics that bypass technical controls. Train users to recognize phishing attempts, suspicious file types, and unsafe browsing practices. This links directly to Control 6.8 (Information security in project management) for security awareness programs.

For cloud environments, reference ISO/IEC 27017 for cloud-specific malware protection guidance, including shared responsibility models where cloud providers handle infrastructure-level protection while customers secure their deployed applications and data.

A.8.8 Management of Technical Vulnerabilities: From Scanning to Remediation

Control 8.8 requires obtaining information about technical vulnerabilities, evaluating organizational exposure, and taking appropriate measures. Most organizations interpret this as "run vulnerability scanners and generate reports," missing the comprehensive vulnerability management lifecycle the control actually demands.

I recently audited a healthcare organization that proudly showed me their weekly vulnerability scan reports—hundreds of pages of findings sorted by severity. When I asked about remediation metrics, they admitted they'd never tracked how many vulnerabilities were actually fixed. Their "vulnerability management" was actually just "vulnerability identification." Six months of critical findings remained unaddressed because nobody had processes for prioritization, assignment, or verification.

Identifying Technical Vulnerabilities

The control requires accurate asset inventory per Control 5.9 (Inventory of information and other associated assets) as a prerequisite. Your inventory must include software vendors, versions, deployment locations, and responsible personnel. Without this foundation, vulnerability management becomes guesswork.

Vulnerability identification encompasses multiple sources:

Automated vulnerability scanning suitable for your technology stack, not generic one-size-fits-all tools
Vendor security advisories for all software in your environment, including embedded systems
Security threat intelligence feeds relevant to your industry and technology choices
Penetration testing by competent personnel to identify logic flaws scanners miss
Third-party library tracking linked to Control 8.28 (Secure coding) for development teams
Bug bounty programs or coordinated vulnerability disclosure processes

Evaluating Vulnerabilities

Evaluation requires risk-based prioritization, not just CVSS scores. Consider business criticality of affected systems, existing compensating controls, attack complexity, and potential business impact. A high CVSS score on an isolated development system may warrant lower priority than a medium score on your customer-facing payment processing system.

Taking Appropriate Measures

The control specifies software update management processes ensuring approved patches install on authorized software. This connects to Control 8.32 (Change management) for normal updates and Control 5.26 (Response to information security incidents) for emergency patching.

When patches aren't available or installable, consider alternative controls:

Network-level filtering to block exploit traffic
Application-level workarounds suggested by vendors
Service disabling for non-essential vulnerable functionality
Enhanced monitoring for exploitation attempts
Virtual patching through web application firewalls

For cloud services, vulnerability management responsibility splits between provider and customer. Review ISO/IEC 27036 for supplier security requirements ensuring cloud providers maintain effective vulnerability management for shared infrastructure.

What the Auditor Looks For

During certification audits, I examine specific evidence demonstrating these controls function in practice, not just on paper:

For Capacity Management (8.6):

Current resource utilization dashboards for security systems with timestamps
Historical capacity trend analysis showing growth patterns
Documented capacity thresholds with automated alerting evidence
Meeting minutes or tickets demonstrating capacity planning decisions
Evidence of capacity expansion implementation before critical thresholds

For Malware Protection (8.7):

Comprehensive inventory of systems with malware protection status
Protection deployment evidence across different system types
Malware detection and response logs with investigation outcomes
Security awareness training records covering malware threats
Testing evidence demonstrating protection effectiveness

For Vulnerability Management (8.8):

Complete asset inventory with software version details
Vulnerability scan results with remediation tracking
Patch deployment records linked to vulnerability findings
Risk-based prioritization documentation with business justification
Compensating control implementation for unpatched vulnerabilities

The most common audit finding across all three controls? Organizations that can demonstrate individual technical implementations but lack documented management processes showing systematic, repeatable approaches to capacity, malware protection, and vulnerability management.

Integration and Cross-References

These controls don't operate in isolation. Effective implementation requires integration with:

Control 5.23 (Information security for use of cloud services) for cloud-based security tools
Control 8.32 (Change management) for security tool updates and configuration changes
Control 5.26 (Response to information security incidents) for emergency patching and malware containment
Control 6.8 (Information security in project management) for security awareness programs

Consider supplementary guidance from ISO/IEC 27032 for cybersecurity and ISO/IEC 27035 series for incident management integration.

Remember: these controls represent the operational backbone of technical security. Implement them systematically with documented processes, regular review cycles, and clear ownership assignments. The goal isn't perfect security—it's managed, measurable risk reduction that scales with your organization's growth and threat landscape evolution.

Need guidance implementing these technical controls effectively? Join the discussion at our ISO 27001 Info Hub or contact us for specialized consultation on operational security management.

Need personalized guidance? Reach our team at ix@isegrim-x.com.