PCI DSS 2.2 expects documented configuration standards that cover all system components, vendor default accounts that are changed or removed, and only necessary services, protocols and daemons enabled. For container images, that means a hardened base, no default credentials, and a minimal set of packages and ports. This is not legal advice.
What the text says
The SAQ D wording gives these items:
- 2.2.1: configuration standards are developed, implemented and maintained to cover all components, address known vulnerabilities, be consistent with industry-accepted hardening standards or vendor recommendations, be updated as new issues are found per 6.3.1, and be applied when new systems are configured.
- 2.2.2: vendor default accounts are managed. If used, the default password is changed. If not used, the account is removed or disabled.
- 2.2.4: only necessary services, protocols, daemons and functions are enabled, and unnecessary functionality is removed or disabled.
- 2.2.5: where insecure services exist, there is a documented business justification and extra security features reduce the risk.
- 2.2.7: all non-console administrative access is encrypted using strong cryptography.
Mapping to a container image
| Requirement | Image practice |
|---|---|
| 2.2.1 standard | A written baseline for approved base images and build rules |
| 2.2.2 defaults | No default or built-in credentials, remove sample accounts |
| 2.2.4 necessary only | Minimal base, remove shells and tools not needed at runtime, expose only required ports |
| 2.2.5 insecure services | Avoid them. If unavoidable, document why and add controls |
| 2.2.7 admin access | Encrypted channels for any remote administration |
| 6.3.1 link | Update the baseline when new vulnerabilities in the base are found |
Container orchestration, registries and hosts are system components too. Cover them in the same standard.
Steps
- Write the baseline: allowed base images, user, filesystem, ports.
- Build images from the baseline in CI so drift is visible.
- Scan every image for known vulnerabilities and unexpected content.
- Fail the build on defined findings.
- Keep the scan output as evidence tied to the image digest.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an image scan reports.
Quick check
Does 2.2 apply to base images I did not build?
2.2.1 covers all system components. Base images you run are components, so include them in your standard.
Is a vulnerability scan enough to satisfy 2.2?
No. 2.2 is about configuration standards, defaults and unnecessary services. Scanning supports 6.3 and 11.3 more directly.
On Safeguard: container image scanning reports known vulnerabilities in image layers, and policies and gates can block a build on a defined result. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.
