11.1 Security testing processes and roles: evidence and audit guide

What PCI DSS 11.1 security testing processes and roles require

PCI DSS 11.1 asks for two things that many organizations already do in practice but cannot show on paper. Requirement 11.1.1 expects the security policies and operational procedures for Requirement 11 to be documented, kept current, in use and known to everyone who performs or depends on them. Requirement 11.1.2 expects the roles and responsibilities for those activities to be documented, formally assigned and understood by the people who hold them. For a PCI DSS 11.1 assessment, the assessor will read the written procedures, compare them with how testing actually happens, and interview the people named as responsible. If a scanning schedule lives in one engineer's head and the penetration test owner has never seen a written procedure, the requirement is not met even when the scans run on time.

The risk is that testing nobody owns or follows lapses quietly. A quarterly internal scan can be skipped after a staff change, a penetration test can be scheduled without anyone accountable for retesting fixes, and wireless or change detection alerts can reach an inbox that no one reviews. Gaps like these tend to surface only when an assessor asks for the last four scan cycles and the evidence is scattered. Before the assessment, confirm that each Requirement 11 activity has a named owner, a written procedure with a review date, and a short RACI matrix that separates who runs a test, who reviews the results and who approves risk decisions. Ask whether the procedures reflect the current environment, including recent changes to the cardholder data environment and its boundaries.

What usually makes this hard is ownership that spans teams. Security may write the testing policy, operations may run the scanners, and an outside firm may perform the penetration test, so each document reflects a different snapshot of who does what. Wiki pages, spreadsheets and ticket templates drift apart, and no one is sure which version is authoritative. A practical fix is to keep one controlled set of Requirement 11 procedures and role assignments, with version history and approval records, and to link each recurring test to its owner. The organization remains accountable for these controls, and an independent QSA or internal assessor will judge whether they are documented and understood. Confirm the exact evidence your assessor expects with them before you finalize the documents.

Which systems, teams and third parties this policy and role set covers

Requirement 11.1 is only as useful as its boundaries. Before writing the testing policy or the roles record, decide which systems it reaches, which teams hold which duties, and which outside parties are named. Each decision below changes who does the work and what evidence an assessor will ask to see.

CDE and connected systems

The testing policy has to name the cardholder data environment and every system that can affect its security, including connected systems, management networks, jump hosts and the segmentation controls that separate them. If the policy stops at the CDE boundary, scans and penetration tests will miss the paths attackers actually use. Check the policy against the current network and data-flow diagrams, and confirm that out-of-scope systems are still covered wherever a segmentation control depends on them.

Security team ownership

The security team usually owns the testing policy, the scan schedule and the review of results, so its role must say who approves a new test type and who signs off on a closed finding. Write down the named role, not just the team name, and record who covers when the primary owner is unavailable. An assessor will interview the people listed, so each one should be able to describe the process without reading it aloud.

Network and platform responsibilities

Network and platform engineers often run the scanner, open the scan paths through firewalls, and apply patches to the systems that scans flag. Their duties should appear in the roles record with the specific tasks they perform, such as credentialed access for authenticated scans or maintenance windows for remediation. Unclear handoffs between these teams are a common reason scheduled tests slip without anyone noticing.

Application and SOC roles

Application teams own findings in their code and must be named for penetration testing support and retesting of fixes. The SOC owns detection signals from intrusion and change detection and must know who to escalate to when a test or scan triggers an alert. Documenting both roles prevents the common gap where a test is run, a result is produced, and no one is accountable for acting on it.

Named third parties

Approved Scanning Vendors, external penetration testers and any managed scanning provider should appear in the roles record with their scope, their contact owner inside the organization, and the deliverables you expect back. Confirm which external scans require an ASV and which tests can be performed internally. Name the outside party only when the contract, scope document and reporting format are agreed, because the assessor will compare the record against what the provider actually delivered.

How a QSA tests 11.1.1 and 11.1.2

This table compares what an assessor examines, asks and requests for each sub-requirement of Requirement 11.1, based on the self-assessment questionnaire expectation to examine documentation and interview responsible personnel. Read each row as a checklist of what must exist on paper and what the people named in it should be able to explain.

Sub-requirement	What the assessor examines	What they ask staff	Evidence requested	Common findings
11.1.1 Policies and procedures	Whether the security testing policy and operational procedures cover wireless detection, scanning, penetration testing, intrusion and change detection, and payment page monitoring, with version history and review dates	Who uses the procedures, how they were communicated, and whether they reflect the scans and tests actually run this year	Approved security testing policy, operational procedures per activity, revision history, distribution or acknowledgment records	Policies that predate the current environment, such as cloud accounts or new payment pages not mentioned, or procedures that no team has read
11.1.1 Currency and use	Whether procedures match recent test records, such as scan reports, pen test reports and change tickets	How a typical test is started, approved and closed, and where the steps are recorded	Sample of recent test records traced back to the procedure they followed	Procedures describe a quarterly process while records show ad hoc testing with no consistent cadence
11.1.2 Roles and responsibilities	Whether each Requirement 11 activity has a named owner, backup and reviewer in a documented record such as a RACI matrix	Who runs scans, who reviews findings, who signs off on penetration test scope, and who responds to detection alerts	RACI or equivalent matrix, job descriptions or role assignments, delegation records for absences	Roles assigned to people who have left, shared mailboxes as owners, or staff who cannot describe their duties
11.1.2 Understanding	Whether responsible personnel understand their assigned activities and where the handoffs between teams sit	What each person is responsible for, how they hand off findings to remediation owners, and what they escalate	Training or briefing records, handoff procedures, escalation paths	Assigned roles exist on paper but the named people say another team does the work
Scope link	Whether the roles and procedures name the systems, networks and payment pages in the current CDE scope	Which systems are in scope for testing and who confirms that list when the environment changes	Scope statement referenced by the testing procedures, asset inventory cross-check	Procedures reference a network diagram or asset list that has not been updated after a migration
Management review	Whether responsibilities are reviewed when staff, systems or vendors change, with dated records	When roles were last reviewed and what changed as a result	Review records, meeting minutes or approvals with dates and names	No review record exists, so assessors cannot confirm the roles still hold

How to build the testing policy and roles record step by step

This sequence turns Requirement 11 activities into a documented policy, procedures and a roles record that an assessor can examine and staff can explain. Each step ends with a named output you can file as evidence.

Inventory the Requirement 11 activities in use
Start by listing every security testing activity your organization actually runs: wireless access point checks, internal and external vulnerability scans, penetration tests, intrusion and change detection, and payment page monitoring. Ask the teams that run each activity, not only the security function, what they do, how often, which systems they cover and which tools they use. Record any activity that is planned but not yet running, so the gap is visible. The output is a single activity inventory with an owner team, tool and cadence for each line. Check it against your cardholder data environment scope so no in-scope system is left without a named testing activity.
Draft the security testing policy and procedures
Write a policy that states why and how your organization tests security, and procedures that describe how each activity in the inventory is carried out. The procedures should name the tool or method, the trigger or schedule, how findings are recorded, and how results reach the people who fix them. Keep the policy at the level of intent and the procedures at the level of steps, so each can be updated without rewriting the other. The output is a versioned policy document and one procedure per activity, stored in a controlled location. Confirm the documents describe current practice, since an assessor will compare them with what the team does.
Assign an owner to each activity
For every line in the inventory, name one accountable owner and, where useful, a backup. Owners are usually people in security, IT operations, application development or a managed provider, but the assignment must be an individual role rather than a team mailbox. Confirm each owner accepts the responsibility and understands the testing they are accountable for. If an activity is performed by an outside party, record that party as the performer while the internal owner keeps accountability. The output is an assignment list tied to the inventory, with names or role titles and the date each assignment was confirmed.
Record roles in a RACI matrix
Convert the assignments into a RACI matrix that shows, for each activity, who is Responsible for performing it, Accountable for its outcome, Consulted before decisions and Informed of results. Include the roles that review findings, approve exceptions, approve scope changes and handle retesting after a fix. A common mistake is to leave the Accountable column empty or to assign two people as Accountable for one activity. The output is a RACI matrix that covers every Requirement 11 activity and every step in the procedures. Check that every row has exactly one Accountable role.
Obtain formal sign-off from management
Send the policy, procedures and RACI matrix to the executive or committee that owns security governance for approval. Record the approver, the approval date and the version number on the policy and the matrix. Sign-off matters because it shows that management has accepted the testing program and the responsibilities within it. Any change to roles after approval should go through the same route. The output is an approved, dated version of each document with the approver named, which is the version you will show an assessor.
Distribute the documents and confirm understanding
Publish the approved documents where affected staff can find them, and notify each named role. Ask each owner to confirm, in writing or through an acknowledgment in your document system, that they have read their responsibilities and know what the activity requires. Follow up with people who do not respond, and brief them directly if they are unclear. An assessor is likely to interview these people, so their answers should match the documents. The output is a distribution record and a set of acknowledgments for each named role, kept with the approved versions.
Set a review cycle and track changes
Define when the policy, procedures and RACI matrix will be reviewed, and what triggers an early review, such as a new system in scope, a tool change, staff turnover or a finding that shows a gap. At each review, check the inventory against current scope and confirm that each owner is still in role. Keep version history so you can show what changed and when. A wiki or document system with version control, such as XWiki, can keep this history, and a role-based wiki such as BookStack can limit who may edit each document. The output is a review record for each cycle and an updated version history. Confirm your own review frequency with your assessor, because the standard requires documents to be kept up to date without fixing a schedule in the facts supplied.

Keeping the testing policy current between audits

The key point is that an assessor of Requirement 11.1.1 will not accept a policy simply because it carries a recent date. They will look for proof that the security testing policy and operational procedures were reviewed, updated when the environment changed, and actually followed between assessments. A version history is the strongest evidence for this. In a wiki such as XWiki, every change to a page is kept under version control, recording what changed, when and by whom, and any two versions can be compared or rolled back. Confirm that your chosen platform keeps that history for the testing procedures, that edits are attributed to named individuals, and that review sign-offs are recorded as their own entries rather than buried in a silent edit.

Change records matter as much as the document. Pair the version history with a dated record of each review, showing who reviewed the policy, what they checked (for example, whether scan frequencies still match the procedures in use, or whether a new payment channel needed its own testing steps), and what was changed as a result. Keep the record of reviews that did not produce changes too, because an unchanged document with a documented review is stronger evidence than a document with no visible review at all. The review interval itself should be the one your organization defines and follows; confirm the expectation with your QSA or the current standard before you set it.

Roles need the same discipline. Requirement 11.1.2 expects roles and responsibilities for scanning, penetration testing and detection to be assigned and understood, so every staff change, contractor rotation or reorganization should trigger an update to the RACI matrix and the responsibilities table in the procedures. In BookStack, user abilities come from assigned roles and can be overridden per shelf, book, chapter or page, so the access model and the documented responsibilities should be reviewed together. A useful check is to ask a recent joiner or a departed owner's successor to explain who runs each test and who reviews the results. If the answer differs from the document, the document is out of date regardless of its date stamp.

Evidence that passes the 11.1 review

Requirement 11.1 is judged on paper and people: a written testing policy, procedures that match what the team actually does, and a roles record that names who acts. Assessors compare these artifacts with each other and with interview answers, so every card below is also a consistency check.

Security testing policy

The policy states why and how Requirement 11 testing happens: which activities run, how often, what counts as a significant change, and who approves exceptions. Assessors read it first and then test whether the scanning, penetration testing and detection work described in it actually occurs. Keep one owner, a named approver and a review date. Confirm the policy is approved by management before each assessment window opens.

Procedures for each Requirement 11 activity

Each activity needs its own runbook: wireless scanning, internal and external vulnerability scans, penetration tests, intrusion and change detection, and payment page monitoring. A procedure should name the tool, the scan profile or test method, the trigger, the ticketing path for findings and the retest step. Check that each procedure matches the tool configuration and recent output, because a mismatch is a common finding.

RACI matrix for testing roles

A RACI matrix maps each Requirement 11 activity to the people who are responsible, accountable, consulted and informed. It should separate the team that runs scans from the reviewer who accepts results and the owner who funds remediation. Interview answers must match the matrix, so confirm that named staff can explain their part without reading it. Re-issue the matrix whenever staff or tooling changes.

Distribution and acknowledgment records

A policy that no one has read does not meet the requirement that procedures are in use and known to affected parties. Keep a distribution list tied to roles, dated acknowledgments from each affected person, and a record of training sessions where the procedures were walked through. Remove leavers from the list and capture acknowledgments from new joiners before they receive access to scanning or testing tools.

Revision history and change log

Assessors look for evidence that documents stayed current, so each policy and procedure needs a dated revision history showing what changed, who approved it and why. Version control in a wiki or document system records this automatically, and users can compare versions and roll back. Review at least once a year and after any change to tooling, scope or the standard itself, and record the review even when nothing changes.

Access control on the documentation

Testing documents often contain network maps, asset lists and finding details that an attacker would find useful, so they need restricted access. Role-based permissions in a documentation platform can limit who edits policies and who only reads them. Keep a record of who holds edit rights and review that list with the RACI matrix each cycle, since stale permissions weaken the evidence that roles are assigned and understood.

What meeting 11.1 costs in money and effort

This table breaks down the one-time and recurring work behind Requirement 11.1, who is paid for each part, and what pushes cost up or down. Read it as a checklist for scoping and for asking an implementation partner or assessor what they will quote. No prices or durations are stated because none are supplied for this requirement.

Cost component	Who bears it	One-time or recurring	What drives it
Policy and procedure authoring for security testing	Internal security or compliance staff, optionally an outside consultant	One-time build, then recurring updates	Number of testing activities in scope, existing policy templates, and how many systems the procedures cover
Role workshops and RACI definition	Security lead, operations, network and application owners	One-time, then recurring when staff change	Number of teams that run scans, penetration tests and detection, and whether responsibilities already have owners
Document version control and wiki tooling	Internal IT or platform team; self-hosted open-source wiki removes the license line	One-time setup, recurring hosting and upkeep	Hosting model, backup and access controls, and whether the tool is in the client's own infrastructure
Role and access management for the documentation system	Internal IT or identity team; self-hosted open-source access tools can remove license spend	One-time configuration, recurring access reviews	Number of roles, how often staff rotate, and how permissions are granted at page or book level
Ongoing review of policies, procedures and role records	Policy owner and each named role holder	Recurring, at least as often as the organization's own review cycle	Frequency of change to systems and scanning tools, and the number of revisions a year
Findings and evidence tracking for testing roles	Security operations or the testing team; open-source findings platforms can remove license spend	Recurring with each test cycle	Volume of tool reports, the number of tools feeding one record, and manual triage effort
Assessor examination and interviews	QSA or internal assessor time, paid by the organization or its assessor firm	Recurring with each assessment	Size of the documentation set, how quickly staff can locate records, and how well interviewees know their duties
Implementation partner support for documents and tooling	Organization pays the partner under a written, fixed-scope agreement	One-time, with optional recurring retainer	Scope agreed in writing, number of platforms and teams, and whether evidence collection is automated

Open-source tools that hold the 11.1 documents and role records

Requirement 11.1.1 expects the security testing policies and operational procedures to be documented, kept up to date and in use. An assessor will ask for the current version and for proof that earlier versions were replaced in a controlled way. XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control, so the history shows what changed, when and by whom. Teams can compare any two versions and roll back to an earlier one when a revision goes wrong.

Change history: Each edit to the scanning, penetration testing and detection procedures is recorded with its author and timestamp.
Version comparison: Assessors can see exactly which steps changed between the prior and current procedure.
Rollback: A wrong revision can be reverted without losing the record that it existed.
Review trail: Teams can record the annual review date in the page itself, so the document shows it is kept up to date.
Self-hosted storage: The wiki runs inside your own infrastructure, so policy records stay under your control.

Before relying on this, confirm with your QSA which form of approval and review evidence they expect, and check that your reviewers actually sign off inside the wiki rather than in email.

Where 11.1 fails in assessments and how to close each gap

Requirement 11.1 is rarely failed because the organization lacks testing tools. It fails when the policy, the people and the records drift apart. The cards below pair each gap an assessor commonly finds with the fix that closes it before the assessment starts.

Policy written for a past environment

A testing policy that names scanners, network ranges or hosting platforms the organization no longer uses tells the assessor the document was not maintained. Requirement 11.1.1 expects the policies and procedures to be kept up to date and in use. Before the assessment, compare each named tool, scope and schedule against the current asset inventory and the current data flow diagrams. Record the review date and who approved any changes.

Roles listed but unknown to the people named

A roles section that assigns scanning, penetration testing and detection duties to people who have never heard of them fails the understanding part of 11.1.2. Assessors commonly test this by interviewing the named individuals and asking what they do during a quarterly scan cycle. Confirm each named person can describe their task, their backup and their escalation path. Where they cannot, either train them and record the training or correct the document.

No record of who reviewed what

Scan results and penetration test reports that exist without a reviewer, a review date or a disposition give the assessor no evidence that anyone acted on them. Requirement 11.1 work depends on a traceable chain from finding to owner to decision. Keep a review log that records who examined each result, when, what was accepted, fixed or deferred, and why. Version control in the documentation platform gives the assessor the change history for the procedure itself.

Testing owned by nobody after a reorganization

A team merger, a cloud migration or a change of vendor often leaves scanning and penetration testing without a named owner while the schedule keeps running. The result is scans that still run but whose findings reach no one. After any reorganization, reassign each Requirement 11 activity in the RACI matrix, confirm the new owner accepts it in writing, and update the escalation contacts. Assessors check whether the roles reflect the current organization chart.

Procedures that exist only in an engineer's head

When the steps for running a scan, triaging a finding or retesting a fix are known only to one engineer, the procedure is not documented, not in use by others and not known to affected parties. Write the steps as numbered procedures with the tool, the configuration, the target list and the expected output. Store them where the team works and have a second person run one cycle from the document alone. That trial run is the most direct evidence that the procedure is usable.

Tools without a consolidated findings view

Scanners, penetration testers and detection tools that report in separate formats make it hard to show one record of testing activity. Assessors then ask for evidence that each activity happened on schedule and was tracked to closure. Consolidate findings from each tool into one tracker with the owner, status and date on every item. A findings platform that imports many report formats and deduplicates results can serve as that record, and its audit trail should be confirmed before relying on it.

Questions buyers ask about 11.1 cost, effort and outside help

How much effort does Requirement 11.1 take to meet in-house?

For most organizations, the effort is documentation and coordination rather than technical build work. Requirement 11.1 asks for a written security testing policy and operational procedures (11.1.1), plus documented roles and responsibilities (11.1.2). The effort depends on how many systems and teams are involved, whether testing procedures already exist for vulnerability scanning, penetration testing and detection, and how many people must review and sign off the documents. The main recurring cost is keeping the documents current and confirming that the named people still hold their roles. Ask your team to inventory existing procedures first, since that usually shows how much is new work and how much is cleanup.

Do we need a consultant to meet Requirement 11.1?

No. The organization owns its controls, so it can write the policy, procedures and RACI matrix itself. A consultant is optional and is most useful when internal staff lack time or experience with PCI DSS wording. The independence line matters: a firm that writes your policies and roles can prepare evidence, but a Qualified Security Assessor (QSA) must still examine the records and interview staff when validating compliance. Keep the firm that drafts your documents separate from the assessor who tests them, and confirm that the assessor is comfortable with how the work was produced before you commit.

How long does it take to produce the 11.1 policy and RACI matrix?

The timeline is driven by scope and review cycles, not by a fixed number of weeks. Key drivers include the number of in-scope teams, whether scanning and penetration testing are already run by named people, how many approval layers the policy must pass, and whether the organization has a document control process. A simple environment with one security team can often finish a first draft quickly, while a larger organization with several outsourced testers needs time to agree on who owns each activity. No duration is specified by the PCI SSC for this step, so plan with your assessor and set milestones in a written scope.

Will a QSA accept a self-assessment questionnaire with these records?

A QSA does not accept a questionnaire on its own. The SAQ is completed on an official PCI SSC template and then supported by an Attestation of Compliance, and the records behind each answer must exist. For Requirement 11.1, the expected testing is to examine documentation and interview responsible personnel, so a current testing policy, procedures and a roles record such as a RACI matrix are the evidence. Confirm with your acquirer or the payment brand which validation type applies to you, because the questionnaire type is not chosen by the PCI SSC. Ask the assessor to review your draft before final sign-off.

What does Requirement 11.1 need from the security and operations leads?

Both leads need to agree on ownership, because 11.1.2 requires responsibilities to be documented, assigned and understood. The security lead typically owns the testing policy and the scanning, penetration testing and detection roles, while operations owns the systems being tested, change windows and remediation of findings. Expect time for a working session to map each activity to a named role, then a review to confirm that staff know their duties. Both leads should also agree how the policy will be kept current when systems or teams change, since out-of-date roles are a common assessment finding.

What should we ask for in a written scope for 11.1 help?

Ask for a written scope that lists each deliverable by name: the security testing policy, the operational procedures for each Requirement 11 activity, the RACI matrix, and the review and approval steps. The scope should state which systems, teams and sites are covered, what the provider will not do, who will hold the final documents, and what changes are excluded. Ask how the work is reviewed, who signs off, and whether the provider will support your assessor's questions. Also confirm the timeline, the milestones, the payment terms and how updates after go-live are handled. Engagements at DeployOpen are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.

What recurring work keeps the 11.1 records valid?

The policy and procedures must stay current, be in use and be known to everyone affected, so the recurring work is review and communication rather than a one-time write-up. Plan an annual review at minimum, plus updates whenever a testing tool, team or in-scope system changes. Keep a change log in your document system so you can show what changed, when and by whom. Staff turnover is the most common cause of stale roles, so check the RACI whenever someone leaves or moves. Ask your assessor which review cadence they expect to see in evidence.

How DeployOpen prepares the 11.1 record with you

DeployOpen helps you build the 11.1 record inside your own environment. Before any drafting starts, we agree in writing which sub-requirement deliverables are in scope: the security testing policy, the operational procedures that cover scanning, penetration testing and detection, and the roles and responsibilities record. Because the engagement is fixed-scope, the deliverables, the systems they cover and the review points are fixed before work begins. Ask for that written scope to name each document by title and state who approves it and who signs off the final version.

Where you agree it, we configure the self-hosted tools that will hold this record. In XWiki, that means a space for the policy and procedures where every change is kept under version control, so an assessor can see what changed, when and by whom. In BookStack, it means a shelf and book structure with role-based permissions, so that only the people named in the roles record can edit the procedures. DefectDojo can hold the findings that show the procedures are being followed. These platforms run on your infrastructure, and your team keeps administrator credentials. Confirm the hosting location, backup arrangements and who holds the administrator accounts before the build starts.

We then assemble an evidence pack that maps each deliverable to the assessor's expected testing for 11.1.1 and 11.1.2: documents examined, a RACI matrix or equivalent roles record, and a short note on how staff were briefed. The organization owns its controls, approves the content and decides whether a policy statement reflects how it actually operates. DeployOpen does not issue reports, attestations or certificates. Validation of Requirement 11 is performed by a Qualified Security Assessor or through a Self-Assessment Questionnaire completed by your organization, and any assessor's conclusions come from that independent party alone.

How DeployOpen approaches PCI DSS 11.1 engagements

DeployOpen helps teams put the security testing policy, procedures and roles behind Requirement 11.1 into a form an assessor can examine. The organization owns its policies and assigns its own people, while DeployOpen prepares the systems, records and evidence that show those policies are in use. Independent QSAs assess the result and issue the reports.

How we scope

We agree a written scope listing which testing processes, teams and systems the engagement covers before work starts.
Scope names the documents to draft or update, such as the security testing policy and operational procedures.
We confirm with your team and assessor which roles need documented responsibilities, such as scanning, penetration testing and detection.

How we build

We draft or revise the testing policy and procedures for your review, then map each step to a named role.
We configure the self-hosted tools that run testing and record results, such as vulnerability management and findings tracking.
We set up a documentation wiki with version history so policy changes and approvals stay traceable over time.

How we hand over

You receive the policy, procedures and roles record in editable form, with a responsibility matrix such as a RACI table.
We deliver a walkthrough so the people named in the roles record can explain their duties to an assessor.
Your organization approves and owns the final documents, and the assessor decides whether the evidence meets 11.1.

How we support

Ongoing support is available as a retainer for updating procedures when roles, tools or the standard change.
Periodic reviews can confirm that documented roles still match who actually runs testing and reviews findings.
Ask any provider to confirm in writing which documents and records they will keep current after the engagement ends.