2.1 Secure configuration processes and roles

What PCI DSS 2.1 asks for: secure configuration policies and roles

Requirement 2.1 asks for two things: the security policies and operational procedures for secure configuration must be documented, kept up to date, in use and known to everyone who builds or runs system components, and the roles and responsibilities for those activities must be documented, assigned and understood. Sub-requirement 2.1.1 covers the policies and procedures themselves, and 2.1.2 covers ownership. The hardening work itself sits in 2.2 and 2.3. Under 2.1, an assessor will want to see the written policy, the procedures behind it, and proof that the people who apply them have read and understood them.

The risk behind 2.1 is inconsistent builds and configuration drift. When nobody owns hardening, each team applies its own baseline, vendor defaults survive into production, and a server rebuilt next year looks nothing like the one audited last year. Because the requirement is mostly about documentation and ownership, it is easy to treat as paperwork. In practice, most gaps come from three patterns: policies written once for an audit and never used, roles that exist only in people's heads, and unclear lines between the platform team, the security team and application teams that each assume another group owns the build standard.

Start by asking who signs off on the configuration standard, who applies it to new systems, and who checks for drift afterward. Record the answers in a roles matrix such as a RACI table, and confirm that each named person can point to the current procedure. Your assessor's testing approach, described in the SSC's self-assessment questionnaire, is to examine documents and interview the responsible staff, so a policy nobody can find or explain will not pass even if it is well written. Confirm the exact evidence expected for your validation type with your assessor or QSA before you build the set.

Which systems, teams and third parties 2.1 covers

Requirement 2.1 applies to every system component in or connected to the cardholder data environment, so the scope you draw determines how many policies, procedures and roles you need. Settle the inventory, the build teams and the third-party boundaries before drafting anything, because each one changes who must be named in the roles record.

Component types in scope

Start with the inventory of servers, network devices, containers, cloud resources and administrator workstations that store, process, transmit or could affect cardholder data. Each type builds and hardens differently, so the secure configuration procedure must name it or explicitly cover it. Ask whether jump hosts, backup systems and management consoles appear in your asset list. If an item is missing from the inventory, it is likely missing from the procedure too.

Build and hardening teams

Identify every team that installs, images, patches or changes in-scope systems, including platform engineering, network operations, database administrators and application teams. Each one needs a documented role under 2.1.2, and each must know the policy under 2.1.1. Teams that work in separate tools, such as infrastructure-as-code pipelines and manual console changes, often follow different unwritten steps. Confirm who may approve a configuration change and who may deploy it.

Cloud and container resources

Cloud accounts, Kubernetes clusters and container images are often created by self-service pipelines rather than by a named administrator. Decide which templates, base images and account settings count as the configuration standard, and who owns each one. Without that decision, a cluster created outside the approved pipeline can fall outside every documented role. Record the ownership boundary between your team and the cloud provider's shared responsibility terms.

Third parties that run parts of the environment

Hosting providers, managed service providers and software vendors may configure systems that sit in your cardholder data environment. Their responsibilities must be written into your roles and procedures, and you must know which of their staff can change your settings. Request each provider's responsibility matrix and confirm which configuration tasks they perform and which remain yours. Service provider duties are covered separately under the service provider guidance.

Connected systems outside the CDE

Systems that do not store card data can still affect its security, for example directory servers, logging collectors, patch repositories and DNS. Decide where your boundary sits and document why each connected system is in or out of the policy's reach. Assessors will test the boundary you draw, so the scope statement and the configuration policy must agree. Revisit this list whenever a new connection to the environment is approved.

How a QSA tests 2.1 and which evidence passes

This table compares each step an assessor takes for 2.1.1 and 2.1.2, what they ask for, the evidence that passes and the findings that appear most often. Read it as a checklist your team can run before the assessor arrives, since the assessor's conclusions appear only in the ROC or SAQ and the AOC.

Test step	What the assessor asks for	Evidence that passes	Common findings
Policy currency (2.1.1)	The written secure configuration policy and its review history	Approved policy with version history, a named owner and a review date within the cycle your organization set	Policy review date has lapsed, or the document has no approval record
Operational procedures (2.1.1)	Step-by-step build and hardening procedures for each system component type	Procedures that match the current build pipeline, images and change tickets for a sample of systems	Procedures describe an older build process, or engineers follow steps not written down
Awareness of affected parties (2.1.1)	Evidence that the people who build and harden systems know the policy and procedures	Acknowledgement records, training attendance or read logs tied to the current version	Staff are unaware the policy exists or work from a copy that was superseded
Roles documented (2.1.2)	A roles and responsibilities record for each Requirement 2 activity, such as a RACI matrix	RACI or equivalent that assigns an accountable owner and a responsible team for every activity	Matrix names people who have left, or leaves activities without an owner
Roles understood (2.1.2)	Interviews with the people named in the record, asking them to explain their duties	Interviewees describe their responsibilities consistently with the documented roles	Staff cannot describe their role or confuse their duties with another team
Sample tracing	Selected systems traced back to the policy, procedure and the person accountable for their configuration	Build records, change tickets or configuration baselines that link a sampled system to the documented process	Records cannot be traced to a named role, or the sampled system was built outside the procedure

How to implement 2.1 in seven steps

This sequence turns requirement 2.1 into a working set of owned roles, approved policies, followed procedures and dated records that an assessor can examine and staff can explain. Each step ends with an artifact you can show.

Inventory who builds, hardens and approves changes
Start by listing every team and individual who builds, images, hardens, deploys or approves changes to system components in the cardholder data environment and in any connected in-scope systems. Include internal platform staff, security engineers, change approvers and any outsourced administrators. Confirm the list with each manager, because informal practice often differs from the org chart. The output is a named owner list with team, function and the systems each person touches. You know this step is done when every in-scope system from your inventory maps to at least one accountable team.
Draft the secure configuration policy
Write a policy that states what secure configuration covers, which system components are in scope, the principles that govern builds and changes, and how exceptions are requested and approved. Name the policy owner and set a review cycle that your organization can actually keep. Keep the draft in a version-controlled wiki or document repository so every edit records what changed, when and by whom. The output is a version-numbered policy with an owner, approval record and review date. Ask your assessor early which format they expect to examine.
Write operational procedures engineers follow
Turn the policy into step-by-step procedures for how systems are built, how baselines are applied, how deviations are logged and how changes are reviewed. Link each procedure to the configuration standards that you own under requirement 2.2, so engineers can see which standard governs which build. Test the procedures against a real build with the people who will use them, and remove any step that nobody performs. The output is a set of procedures with identifiers, owners and cross-references to the standards. You know this step is done when a new engineer can follow a procedure without asking a colleague how it works.
Define roles and responsibilities in a RACI
Build a RACI matrix that assigns Responsible, Accountable, Consulted and Informed roles for each requirement 2 activity, such as drafting a baseline, approving an exception, applying a hardening change, and reviewing a deviation. Make sure every activity has exactly one accountable owner and that each named role appears in the owner list from step one. Circulate the matrix to the people named in it and record their confirmation that they understand their duties. The output is a versioned RACI with sign-off. You know this step is done when no activity lacks an accountable owner.
Publish documents and record staff awareness
Publish the approved policy, procedures and RACI in the location where affected staff will look for them, and restrict edit rights to the named owners. Notify everyone on the owner list, then collect acknowledgment that they have read and understand the documents that apply to them. Keep acknowledgments tied to document versions so you can show which version each person accepted. The output is a publication record and acknowledgment records per person and version. Confirm with your assessor how they plan to interview staff, since the expected testing includes interviews with responsible personnel.
Run the first review cycle
Conduct a documented review of the policy, procedures and RACI against the current system inventory and any changes made since publication. Check that the roles still match who actually builds and approves changes, and that the procedures still point to current standards. Record each finding, the decision taken and the new version number. The output is review minutes, a change log and any updated document versions. You know this step is done when the review record shows what was checked, by whom and what changed as a result.
Assemble the evidence pack
Gather the approved policy, procedures, RACI, acknowledgment records, review records and version history into one indexed folder that maps each artifact to sub-requirement 2.1.1 or 2.1.2. Add a short cover note naming the owners and the review date. Prepare a walkthrough so a responsible person can explain how the documents are used in daily work. The output is an evidence index that an assessor can navigate without help. Ask your QSA or internal assessor to confirm the format and retention approach before the assessment begins.

Evidence that passes a 2.1 review and how to keep it current

An assessor testing 2.1 looks for two things: written policy and procedures that people actually follow, and a record of who is responsible for each activity. The cards below cover the artifacts that show both, how each stays accurate between assessments, and who should own its upkeep. Ownership is the organization's responsibility; an implementation partner can help build and document these records, but only the independent assessor reviews them.

Approved secure configuration policy

This is the top-level policy that sets the organization's intent for secure configuration of every system component in scope. Assessors check that it is documented, approved by management, and carries a version history showing what changed and who approved it. Keep it in a wiki with version control so every edit is traceable. Between audits, the policy owner, usually the CISO or a security governance lead, should confirm the document still matches the current system inventory and the scope of the cardholder data environment. Check that the approval date and review date are visible on the document itself.

Operational secure configuration procedures

Procedures turn the policy into steps that engineers follow when they build, harden and change systems. Examples include how a new server is built from a hardened standard, how deviations are approved and how configuration drift is reported. Assessors compare procedures against what staff describe in interviews, so every procedure should name the tool or template used. Platform or infrastructure leads own these documents and should update them after every significant tooling or platform change, not only at the annual review.

RACI or roles record

A RACI matrix maps each Requirement 2 activity to the person or team that is responsible, accountable, consulted and informed. It is the main artifact that answers 2.1.2, which asks that roles and responsibilities be documented, assigned and understood. Check that every activity in the procedures appears in the matrix and that no activity has two accountable owners. The compliance lead maintains the matrix and the accountable executive signs off on changes after organizational moves or staff departures.

Staff acknowledgment and training records

Assessors look for evidence that the people named in the policy and procedures know what they say. Signed acknowledgments, training completion logs and quiz results for engineers and administrators all serve this purpose. Keep a register that lists each affected person, the document versions they acknowledged and the date. Whenever the policy or procedures change, re-acknowledgment should be triggered. HR or the learning owner maintains the register, while the security team defines which roles must acknowledge which documents.

Review and approval records

Documents are only current if someone checked them at the interval the organization set. Review records show the reviewer, the date, the outcome and any changes made. Confirm that the review interval in the policy matches what was actually performed, because assessors often find gaps between the stated cycle and the dates on the page. Assign a document owner who receives calendar reminders, and archive superseded versions so the assessor can see the history without confusion.

Job descriptions and ownership assignments

Job descriptions and team ownership records should reflect the responsibilities in the RACI. If the matrix assigns hardening of build images to a platform team, the role definitions for that team should say so. Mismatches between documents are a common finding because they suggest that responsibilities exist on paper only. HR and line managers own job descriptions, and the compliance lead should check them against the RACI whenever a role changes or a new team takes over a system.

Change tickets showing roles in action

Records of roles acting on the procedure are the strongest proof that 2.1 is operating. Change tickets, hardening exception approvals, build pipeline logs and configuration baseline reviews show who did what, when, and under which procedure. Choose a sample of recent changes to walk an assessor through, and confirm that each ticket names an owner from the RACI. The change or platform owner keeps these records, and the security team spot-checks them each month so gaps are found before the assessment.

What meeting 2.1 costs in money and effort

This table breaks down the cost of meeting Requirement 2.1 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since no supplied figures exist for these costs and the real amounts depend on your own environment.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Writing and approving the secure configuration policy and procedures	Internal security or platform staff, plus an approver such as the CISO or risk owner	One-time to draft, then recurring to review and update	Existing configuration standards that can be reused lower the drafting effort; more component types raise it
Agreeing the roles and responsibilities (RACI) across teams	Team leads from platform, operations, network, application and security teams	One-time to agree, recurring when teams or owners change	Number of teams that build or harden systems; unclear ownership extends the negotiation
Document tooling for version control and access control	Internal IT for setup, administration and access reviews; license spend if a commercial tool is used	Setup is one-time; licenses and administration recur	Choice of tool and whether it is already licensed. Self-hosted open-source wikis can remove license spend, but staff still administer and back them up
Collecting acknowledgments and keeping review records	Policy owners and managers who confirm that affected staff know the policy and procedures	Recurring with each policy revision and each staff change	Headcount of affected personnel and staff turnover; automated acknowledgment steps reduce chasing
External review or consulting support, if you hire help	Consultant or implementation partner, billed under a written scope	Usually one-time for drafting or review, with optional retainers	Current documentation quality, number of third parties involved, and how much of the drafting you hand over
Assessor time during the validation	Qualified Security Assessor or other assessor, paid by your organization under their engagement terms	Recurring with each assessment cycle	Quality of evidence on hand, clarity of roles and the number of teams the assessor must interview
Internal time to answer assessor questions and produce evidence	Policy owners, system administrators and the compliance lead	Recurring with each assessment cycle	Central, versioned evidence reduces the search time; scattered documents extend interviews

Open-source tools that hold 2.1 documents and records

Requirement 2.1 is satisfied by documents and people, not by software alone. The four tools below help keep the secure configuration policy, procedures and role records current, show who changed them, and produce operational evidence that the procedures are in use. Each one covers a different part of that evidence trail.

XWiki for controlled policy documents

XWiki (LGPL-2.1-or-later) is a wiki that keeps every page change under version control, recording what changed, when and by whom. An assessor reviewing the secure configuration policy can compare any two versions and see the approval history, and a team can roll back a bad edit. Check that the approval step for policy changes is written into your procedure, because the wiki records edits but does not enforce review.

BookStack for access to procedures

BookStack (MIT) organizes content into shelves, books, chapters and pages, and assigns user abilities through roles. Permissions can be overridden at each level, so you can let the build team edit hardening procedures while others only read them. This helps show who is allowed to change each procedure, which is the question an assessor asks when testing 2.1.2. Review the role assignments periodically, since an overridden permission can outlast the reason for it.

Wazuh configuration assessment output

Wazuh (GPL-2.0-only) Security Configuration Assessment runs YAML policies against monitored endpoints. These policies are mostly based on CIS benchmarks, can be extended with custom checks, and inspect files, directories, registry keys and running processes, with remediation advice in the results. Its output does not replace the policy. It supports the configuration standard described under 2.2 by showing which endpoints deviate from it. Confirm your license obligations for GPL-2.0-only use with counsel before modifying or distributing the software.

Fleet policies as in-use evidence

Fleet (MIT) policies are yes or no questions asked of devices as osquery queries, such as whether a setting is enabled on a host. The policies page shows which devices in each fleet pass or fail. Results from these checks give evidence that the documented procedure is being followed on real devices, not just written down. Decide in advance who reviews failing devices, how fast they are triaged, and where those decisions are recorded, because a dashboard alone does not show follow-up.

Who owns 2.1: your team, a partner and the assessor

Your organization is the owner of 2.1. The policy and operational procedures for applying secure configurations must reflect how your environment is actually built and changed, and only your people can confirm that. Your leadership should approve the policy, your system owners should approve the procedures that touch their platforms, and someone accountable should keep both current when systems, teams or the standard itself change.

Owning the policy: Set the purpose, scope and authority of the secure configuration policy and make a named executive accountable for it.
Approving procedures: Confirm the operational steps for building, hardening, reviewing and changing system components match what engineers really do.
Naming the roles: Assign who builds, who approves, who verifies and who handles exceptions, and record each assignment in a RACI matrix or equivalent.
Keeping records current: Set a review cycle, record approvals and make sure every affected team can find the current version.
Confirming staff awareness: Make sure the people named in the roles can explain their duties, because assessors interview them.

Before any outside party begins work, confirm internally who holds each of these duties and that the named people accept them in writing.

Where 2.1 fails in practice and how to close each gap

Requirement 2.1 rarely fails because nobody wrote a policy. It fails when the document goes stale, the procedures drift from practice, or the roles no longer match who builds and hardens systems. The cards below cover the gaps assessors most often find, with a concrete fix you can assign to an owner.

Policy past its review date

The secure configuration policy exists, but its review date has passed and it still names old platforms, retired tools and a previous owner. Under 2.1.1 the policy must be kept up to date and in use, so an out-of-date document is a finding even when the content was once correct. Check the document's review date, approval record and named owner against the current environment. Assign the policy owner a review cycle in your document system, with a dated sign-off by the security lead and a note of what changed in each revision.

Procedures that describe work nobody does

The procedure says every server is built from a hardened image and checked against a configuration standard, but engineers build some hosts by hand and skip the check when deadlines are tight. Assessors compare procedures with what they observe and interview staff, so the gap shows quickly. Walk through two or three recent builds with the people who did them, then rewrite each step to match the real process or change the process to match the written one. Record the decision in the procedure.

RACI that names departed staff

The roles matrix lists engineers who left the company, omits the cloud platform team and ignores the container group that now builds most workloads. Under 2.1.2, roles for Requirement 2 activities must be documented, assigned and understood, so a matrix that does not match the current teams fails the requirement. Reconcile the matrix against the current directory and the infrastructure-as-code repositories, confirm who approves changes in each platform, and add a review trigger to joiner, mover and leaver steps.

Roles assigned but never acknowledged

The matrix says the platform lead owns hardening for the database cluster, but nobody has confirmed that person understands the duty. Assessors interview responsible personnel, and a role that the holder cannot describe will not satisfy 2.1.2. Ask each named role holder to confirm their responsibilities in writing and to describe the configuration standard they apply. Keep the acknowledgments with the matrix and repeat them when roles change. Permissions in your wiki or documentation platform can reflect the same ownership, which keeps edit rights aligned with stated responsibility.

Policy scoped only to the data center

The policy covers physical servers in the data center and says nothing about cloud accounts, virtual machines, containers or SaaS components in the cardholder data environment. Requirement 2.1 applies to all system components in scope, so an assessor will ask how cloud resources are configured and who owns them. Inventory every platform that hosts or connects to the CDE, then add a section for each platform type that names the configuration baseline, the builder and the owner. Ask the assessor early whether the scope of the policy matches the environment.

Change history that cannot show who changed what

The policy was edited in a shared folder, file names carry dates in place of versions, and nobody can say which revision was in force on the day of an assessment. Under 2.1.1 you need to show the document was current and approved, so a missing trail becomes a finding. Move the policy and procedures into a platform that keeps version history with author and timestamp, and confirm you can compare and restore earlier revisions. Export the approved version and its approval record as dated evidence at each review.

Common questions about 2.1 cost, effort and outside help

Can we write the Requirement 2.1 policy and procedures ourselves?

Yes, in most organizations the security or IT team writes the secure configuration policy and procedures in-house, and the organization owns them. The policy must be documented, kept up to date, in use and known to everyone who builds or hardens systems in scope. Outside help is useful for checking that the document matches how your systems are really built, but the content and approval stay with your organization. Plan for a named owner who reviews the document on a set cycle and records each revision.

What drives the cost and effort of meeting requirement 2.1?

The cost of 2.1 is mostly staff time, because it is a documentation and governance requirement rather than a technology purchase. Effort rises with the number of system types in the cardholder data environment, the number of teams that build or harden systems, and how much existing material is scattered across tickets, wikis and personal notes. Costs are one-time for the first policy and role set, then recurring for annual review and updates after architecture changes. Ask any provider to price the drafting, the review cycle and the staff interviews separately.

How long does it take to document secure configuration roles and policies?

The timeline depends on how many teams build systems and how much of the process already exists in writing. A small team with one platform and clear ownership can usually document the policy and roles in a short period, while a larger organization with several platform teams needs time for agreement on owners and for interviews. No duration figure has been established for this requirement in the sources available here, so ask any provider for a milestone plan with dates in the written scope. Expect the assessor to test that people actually follow the documents, so allow time for staff to use them before the assessment.

What do our engineers and managers need to contribute to 2.1?

Engineers need to confirm how systems are built today, including the images, templates and manual steps they follow, and managers need to confirm who is accountable for each activity. Assessors interview these people, so each person named in the roles record must be able to describe their part. Security and compliance staff review the policy against actual practice. Expect several working sessions, and make sure leaders sign off on the roles record so it is treated as authoritative.

Does a consultant's work on 2.1 count as PCI DSS validation?

No. A consultant's documents and gap analysis are preparation, and they do not validate compliance. Validation comes only from the assessor's Report on Compliance (ROC) completed by a Qualified Security Assessor, or from a Self-Assessment Questionnaire (SAQ), in each case with an Attestation of Compliance (AOC). The PCI SSC also states that certificates are not recognized as validation. Your organization owns its controls, the implementation partner prepares evidence, and only the assessor reports on it.

Can we finish requirement 2.1 before requirement 2.2?

Yes, and it is a sensible order. Requirement 2.1 asks for the policies, procedures and roles that govern how configurations are applied, while 2.2 asks for the configuration standards and hardening of each component. The 2.2 standards are the content that the 2.1 procedures will reference, so drafting 2.1 first gives the hardening work an owner and a process. In practice, teams often draft both in parallel, so the roles record can name who approves each configuration standard.

What should we ask for in a written scope and quote for 2.1?

Ask for a written scope that lists the deliverables, such as the secure configuration policy, the operational procedures, the roles and responsibilities record, and the review schedule. The quote should show which work the provider performs, which work your staff performs, and which work the assessor performs. Ask how the provider will support staff interviews and evidence collection, what happens if systems in scope change, and how revisions are handled after delivery. Confirm the start and end dates in writing, along with the assumptions behind them.

Which open-source tools can keep 2.1 evidence current?

A wiki with version control helps keep policies and procedures current, because it records what changed, when and by whom, and allows comparison and rollback. XWiki is one option that keeps every page change under version control. BookStack can assign access by role at shelf, book, chapter or page level, which helps keep the document owners clear. Tooling does not replace the policy, but it gives assessors a traceable history. Confirm each platform's capabilities against your own environment before you rely on them.

How DeployOpen prepares 2.1 documentation and evidence

DeployOpen helps teams build the secure configuration policies, operational procedures and roles records that Requirement 2.1 expects, and sets up the open-source systems that keep them current. The organization owns its policies and its compliance decisions, and a QSA or ISA issues any assessment report.

How we scope

Agree in writing which system components, teams and documents fall under the 2.1 work.
Confirm which people build and harden systems, so roles can be named and assigned.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts.

How we build

Draft the secure configuration policy and operational procedures for your review and approval.
Configure a version-controlled documentation wiki and role-based access for the policy set.
Set up configuration assessment checks that show whether systems follow the documented standards.

How we hand over

Deliver the policy set, procedures and a roles and responsibilities matrix with named owners.
Walk responsible personnel through the documents so they can explain their duties to an assessor.
Document the open-source tooling, its configuration and the version history that supports the evidence.

How we support

Ongoing support, upgrades and reviews are available as a retainer after handover.
Review policies and roles when staff change or when your environment changes materially.
Ask your QSA or ISA which evidence formats they accept before the assessment begins.