What should 1.1.6 documentation include?

• A. Documentation of all services without business justification or approval.
• B. Documentation of business justification & approval for use of all services, protocols & ports allowed, including security features implemented for insecure protocols.
• C. No documentation is required for allowed services.
• D. Only a list of allowed protocols is required.

Answer: (B)

The main idea being tested is how PCI DSS requires formal documentation around the services, protocols, and ports that are allowed in the cardholder data environment. Specifically, the documentation must include the business justification and formal approval for using every service, protocol, and port, and it must describe the security features in place for any insecure protocols.

This is about ensuring you don’t have unmanaged or unknown services running in the environment. By capturing the business reason and who approved each allowed service, you create accountability and a clear trail for audits and change management. At the same time, noting the security measures for insecure protocols shows you’re actively mitigating risk rather than tolerating insecure practices. For example, if an organization must allow a remote management protocol that is considered insecure, the documentation should state why it’s needed, exactly which ports/protocols are allowed, and what protections are in place (like encryption, strong authentication, restricted access, logging).

Why the other options don’t fit: documenting services without any business justification or approval removes the essential governance and accountability. Claiming no documentation is required contradicts the need for controlled, auditable changes. And only listing allowed protocols omits the required business justification and the security measures for insecure protocols, leaving gaps in risk management.