PCI DSS 2.2.5: Documenting Business Justification for Insecure Services
Running insecure services, protocols, or daemons isn't always avoidable—legacy systems, vendor constraints, and business requirements sometimes demand it. PCI DSS 2.2.5 requires you to formally document why these services exist and prove you've added compensating security controls. This control bridges the gap between security ideals and operational reality.
What this means
This control addresses the reality that some organizations must run insecure services, protocols, or daemons for business reasons. Rather than prohibiting them outright, PCI DSS 2.2.5 requires: (1) documented business justification explaining why the insecure service is necessary, (2) evidence that alternative secure solutions were evaluated or ruled out, and (3) implementation of additional security features (compensating controls) to mitigate the risk. This prevents organizations from leaving dangerous services active without accountability.
How to comply
- 1.Identify all insecure services, protocols, and daemons running in your environment (e.g., Telnet, HTTP, SNMP v1, FTP)
- 2.Document the business justification for each: why it's needed, what business process depends on it, and why alternatives aren't viable
- 3.Record the evaluation of secure alternatives and document reasons for rejection if applicable
- 4.Implement compensating controls such as network segmentation, encryption, access restrictions, or monitoring
- 5.Obtain written approval from management or your compliance officer for the documented justification and compensating controls
- 6.Review and update justifications annually or when services change
- 7.Maintain evidence of all documentation for audit purposes
Evidence auditors look for
- Inventory of insecure services with business justification statements attached
- Risk assessment documenting why secure alternatives (e.g., SSH instead of Telnet) were not adopted
- Network segmentation diagrams showing isolation of insecure services
- Firewall rules limiting access to insecure services by source IP or network segment
- Encryption implementation (TLS/SSL tunneling) wrapping insecure protocols
- Enhanced logging and monitoring rules specific to insecure service traffic
- Management approval memo authorizing continued use of insecure services with compensating controls
- Annual review documentation confirming justifications remain valid
Frequently asked questions
When will FAQs be available?
The FAQ for this control is currently being prepared.
GRCWatch automates insecure service inventory discovery, flags services requiring justification, and organizes compensating control evidence in a single audit-ready repository—eliminating manual tracking and version control headaches.
See how GRCWatch handles this control automatically
Start free trial