This policy establishes the requirements for the secure configuration, management, and maintenance of all information technology systems and assets throughout their lifecycle at [Company Name]. The purpose is to ensure systems are hardened against threats, configured consistently according to approved baselines, inventoried accurately, patched promptly, monitored effectively, and securely decommissioned. This minimizes security risks, ensures operational stability, protects sensitive data (including but not limited to cardholder data), and supports compliance with regulatory requirements, including PCI DSS 4.0.1.
Scope
This policy applies to all company-owned or managed IT assets, including servers (physical and virtual), workstations, laptops, mobile devices (if accessing company resources), network devices (routers, switches, firewalls, VPNs, wireless APs), operating systems, databases, applications (developed in-house or commercial off-the-shelf), cloud services (IaaS, PaaS, SaaS configurations), and IoT devices. It covers all environments including production, development, testing, and disaster recovery, with specific attention to systems within or impacting the Cardholder Data Environment (CDE). All employees, contractors, consultants, and third parties involved in the design, deployment, configuration, management, or decommissioning of these assets are subject to this policy.
Roles and Responsibilities
Role/Group
Key Responsibilities
Executive Management
Provide oversight and resources for system and configuration management; Establish risk tolerance regarding system security and stability.
CISO/IT Director
Own and approve this policy; Oversee the implementation and effectiveness of system hardening, configuration management, patching, and related controls.
Information Security Team
Develop and maintain secure configuration standards (baselines); Conduct vulnerability scans and penetration tests; Monitor system compliance; Review and approve security configurations; Manage security tools (e.g., VA scanners, config monitoring).
IT Operations/System Administrators
Implement and maintain systems according to approved build standards; Apply patches and configuration changes; Manage configuration backups; Maintain asset inventory; Respond to alerts; Perform decommissioning tasks.
Network Engineering Team
Implement and maintain secure configurations for network devices according to standards; Manage network configuration backups.
Application Development Team
Develop applications using secure coding practices; Ensure applications function correctly on hardened systems; Participate in secure configuration definition for application platforms.
System/Application Owners
Define functional requirements; Participate in defining secure configurations for their systems; Approve changes affecting their systems; Ensure systems are included in inventory and monitoring.
Change Advisory Board (CAB)
Review and approve significant configuration changes, system deployments, and decommissioning activities impacting critical systems or the CDE.
Compliance/Audit Team
Periodically review system configurations, patch levels, inventory accuracy, and process documentation for compliance and effectiveness.
All Users
Use systems according to acceptable use policies; Report suspected security issues or performance anomalies promptly.
Policy Requirements
1. Asset Management Policy
Inventory: Maintain a comprehensive and accurate inventory of all IT assets within the scope of this policy. The inventory must include, at a minimum: asset identifier, type, location (physical/logical), owner, classification/criticality, operating system/firmware version, and status (e.g., production, test, decommissioned). Systems within the CDE must be explicitly identified. (PCI DSS Req 2.4).
Ownership: Assign ownership (business and technical) for each asset in the inventory.
Classification: Classify assets based on criticality and the sensitivity of data they process or store, aligning with the Data Classification scheme.
Review: The asset inventory must be reviewed and updated at least quarterly, or more frequently upon changes (commissioning, decommissioning, significant configuration changes). Automation should be used where feasible to maintain inventory accuracy.
2. System Configuration Policy / Secure Build Standards
Baseline Configurations: Develop, document, and maintain secure baseline configuration standards for all operating systems, network devices, databases, applications, and cloud services. Standards must be based on industry best practices (e.g., CIS Benchmarks, DISA STIGs) and vendor hardening guidelines.
Hardening Requirements: Baseline standards must include, at a minimum:
Changing all vendor-supplied default credentials (passwords, SNMP strings) before deployment (PCI DSS Req 2.2.2, Req 2.2.3).
Disabling or removing unnecessary services, protocols, daemons, and functions (PCI DSS Req 2.2.4).
Removing unnecessary default accounts or disabling them (PCI DSS Req 2.2.3).
Server Build Standard: A specific, documented standard must exist for building servers (Windows, Linux, etc.), incorporating the baseline hardening requirements, standard software stack, monitoring agents, and initial patching levels. Builds should be automated where possible to ensure consistency.
Single Functionality: Configure servers and system components to perform only necessary functions required for their specific role in the environment. For example, web servers, database servers, and DNS servers should be implemented on separate systems or securely isolated virtual instances (PCI DSS Req 2.2.1).
Compliance Monitoring**: Implement automated tools where feasible to monitor system configurations against approved baselines and detect unauthorized changes or configuration drift. Address deviations promptly.
Review: Baseline standards must be reviewed and updated at least annually, or when significant new threats or vulnerabilities emerge.
3. Patch Management
Implement a formal patch management process to identify, risk-assess, test, deploy, and verify security patches for all systems and software within scope.
Monitor reputable sources for security patch information (e.g., vendor notifications, CERT alerts).
Risk-rank patches based on vulnerability severity (e.g., CVSS score) and asset criticality.
Deploy critical/high-risk patches within defined timeframes (e.g., 30 days for critical, 90 days for high). PCI DSS requires critical vulnerabilities to be addressed promptly (Req 6.3.3 requires addressing within 30 days for internet-facing CDE components).
Test patches in a non-production environment representative of production systems before widespread deployment, where feasible.
Maintain records of patch deployment status and any exceptions (which require documented risk acceptance and compensating controls).
4. Vulnerability Management
Implement a vulnerability management program that includes regular internal and external vulnerability scanning, performed by qualified personnel or approved scanning vendors (ASVs for external PCI scans).
Conduct authenticated internal scans and external scans at least quarterly, and after any significant change.
Remediate identified vulnerabilities according to risk ratings and timelines defined in the Patch Management process. High/Critical vulnerabilities in the CDE require prioritized remediation.
Perform annual penetration testing (internal and external, including network and application layers), or more frequently based on risk. Segmentation checks must be performed every six months for CDE environments.
Address findings from scans and penetration tests in a timely manner, documenting remediation efforts.
5. System Commissioning Checklist & Process
Implement a formal process for commissioning new systems or significant upgrades into the production environment.
A System Commissioning Checklist must be completed before go-live, verifying:
System is registered in the Asset Inventory.
System is built according to the approved Secure Build Standard and baseline configuration.
All vendor defaults are changed.
All applicable security patches are installed.
System is hardened (unnecessary services/ports disabled).
Monitoring/logging agents are installed and functional.
Configuration backups are scheduled.
Vulnerability scan completed with no outstanding critical/high vulnerabilities.
System documentation (build guide, topology impact) is complete.
Formal approval obtained from System Owner, Information Security, and via Change Management process.
Documentation of checklist completion must be retained.
6. Configuration Backup Policy
Implement procedures to back up critical system configurations for all key infrastructure components, including network devices (firewalls, routers, switches), servers (OS configuration), security appliances (IDS/IPS, WAF), and critical applications.
Define backup frequency based on change frequency and criticality (e.g., daily for frequently changing firewalls, weekly for stable servers).
Store configuration backups securely, with access restricted to authorized personnel. Consider storing copies offsite or in a separate security domain.
Periodically test the restoration process for critical configuration backups (at least annually) to ensure recoverability.
Document backup schedules, storage locations, retention periods, and restoration procedures.
7. Legacy System Security Plan
Identify and inventory all systems considered "legacy" – those that cannot fully meet current security standards (e.g., cannot be patched, use unsupported OS/software, lack required security features).
For each legacy system, develop a Legacy System Security Plan that includes:
Documented business justification for continued use.
Formal risk assessment identifying specific vulnerabilities and potential impacts.
A defined plan and timeline for migrating away from or decommissioning the legacy system.
Legacy System Security Plans require formal risk acceptance by Executive Management and the CISO, reviewed at least annually. Access to legacy systems must be strictly controlled.
8. Decommissioning Process
Implement a formal process for securely decommissioning systems and assets when they are retired or replaced.
Data Removal: Ensure all sensitive data (including CHD, PII) is securely removed from systems/media prior to disposal or reuse, using methods aligned with the Data Protection & Encryption Policy (e.g., secure wipe per NIST SP 800-88, degaussing, physical destruction). Retain records of data destruction.
Access Removal: Remove all system access accounts and network connectivity associated with the decommissioned asset.
Inventory Update: Update the asset inventory to reflect the decommissioned status.
Configuration Removal: Remove related configurations from other systems (e.g., firewall rules, monitoring checks, backup jobs).
Documentation: Document the decommissioning steps taken, including data destruction verification, and retain records for audit purposes.
9. Monitoring and Logging
Implement system-level logging to record security-relevant events (logins, access changes, administrative actions, errors) according to the Access Management and Data Protection policies.
Enable logging on all system components, synchronize clocks using a central time source (NTP), and forward logs to a central SIEM system.
Monitor systems for security alerts, performance issues, and indications of compromise or misconfiguration. Integrate configuration monitoring alerts into the SIEM/SOC workflow.
Enforcement
Failure to comply with this System & Configuration Management Policy may result in disciplinary action, up to and including termination of employment or contract, in accordance with established HR policies and contractual agreements.
Systems found to be non-compliant with configuration standards or patching requirements may be quarantined or disconnected from the network until remediated.
Exceptions to this policy (e.g., delayed patching, deviations from baseline) require a documented business justification, formal risk assessment identifying potential impacts and compensating controls, and written approval from the CISO/IT Director. Approved exceptions must be time-bound and reviewed regularly (e.g., quarterly).
Revision History
Version
Date
Author
Change Details
1.0
[Date]
[Author Name]
Initial policy release
[Ver #]
[Date]
[Author Name]
[Summary of changes]
Approval
Name
Title
Signature
Date
[Exec Name]
[Executive Title, e.g., CTO]
[Date]
[CISO Name]
[CISO/IT Director Title]
[Date]
Appendix A: System Commissioning Process Flow
graph TD
A[Request New System or Upgrade] --> B{Define Requirements and Config}
B --> C[Build System per Standard]
C --> D[Apply Patches and Harden]
D --> E[Install Monitoring and Backup Agents]
E --> F{Perform Vulnerability Scan}
F --|Vulnerabilities Found|--> G[Remediate Vulnerabilities]
G --> F
F --|Clean Scan|--> H[Complete Commissioning Checklist]
H --> I{Security and Owner Approval?}
I --|Yes|--> J{"Submit Change Request (CAB)"}
I --|No|--> K[Address Issues or Reject]
K --> B
J --|Approved|--> L[Deploy to Production]
L --> M[Update Inventory and Documentation]
M --> N[System Operational]
subgraph Preparation_Build
A
B
C
D
E
end
subgraph Validation_Approval
F
G
H
I
J
K
end
subgraph Deployment_Closure
L
M
N
end
Appendix B: Server Build Standard - Key Elements Example
Operating System: Approved OS version (e.g., Windows Server 2022 LTSC, RHEL 8.x). Install minimal required components/roles.
Partitioning: Standard disk layout (e.g., separate OS, logs, application data partitions).
Patching: OS and critical applications patched to current approved level (Patch report attached).
Security Software: EDR agent installed, reporting to console; Monitoring agent installed, reporting; Backup agent installed, first backup scheduled.
Logging: Logs being forwarded successfully to SIEM; Critical event logging verified.
Network Config: Static IP assigned (if required); Firewall rules requested/approved (CR#); DNS records created.
Access Control: Administrative access restricted to authorized groups; MFA confirmed for admin access.
Vulnerability Scan: Scan completed post-build/patching (Report attached); No Critical/High vulnerabilities outstanding OR risk acceptance documented (Ref#).
Configuration Backup: Configuration backup job created and scheduled.
Documentation: System diagrams updated; Runbook/operational procedures drafted/updated.
Approvals: System Owner Sign-off; Information Security Sign-off; Change Request Approved (CR#).
Appendix D: Decommissioning Process Checklist - Example
Authorization: Change Request approved for decommissioning.
Communication: Notify relevant users/system owners of schedule.
Application Removal: Uninstall/disable applications gracefully; migrate application data if needed.
Data Backup (Final): Perform final backup if required for archival (confirm retention needs).
Data Sanitization: Securely wipe/destroy storage media according to Data Protection policy (Method used:, Verification:, Date:, By:). Record serial numbers of destroyed media if applicable.
Network Isolation: Disconnect network cables; remove system from VLANs.
Configuration Removal: Remove firewall rules, DNS records, monitoring checks, backup jobs, application integrations related to the system.
Access Removal: Remove system accounts from directories (AD etc.); Remove system from domain; Revoke service account credentials used by the system.
Inventory Update: Mark asset as "Decommissioned" in CMDB/Inventory; Record disposal date/method.
Physical Disposal: Arrange for secure physical disposal or return of leased equipment.
Documentation Finalization: Update all related documentation; Close Change Request.
Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below.
Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy
