What PCI DSS 1.1 asks for before any firewall rule is written
Requirement 1.1 asks for two things: documented, current security policies and operational procedures for network security controls (NSCs), known to everyone affected, and roles and responsibilities for Requirement 1 activities that are documented, assigned and understood. If an assessment is coming and your firewalls, routers and cloud security groups run without written rules for how they are managed, 1.1 is the gap to close first. An assessor will read the policy, read the procedures, and interview the people who run the controls to confirm that the paper matches practice. The reason 1.1 comes first is that every other Requirement 1 control depends on it. Ruleset standards, change approval, quarterly or six-monthly reviews and the restriction of traffic into and out of the cardholder data environment all need a named owner and a written method. Version 4.x uses the term NSC instead of firewall because the PCI SSC glossary defines NSCs as firewalls and other network security technologies that act as network policy enforcement points. Your policy should therefore cover every enforcement point in scope, including cloud security groups and network access controls, not only the appliance your team calls the firewall.
Two problems make 1.1 harder than it looks. The first is policy that describes an older network: a document written for a data center that has since moved partly to cloud, or a procedure that names a retired firewall model. An assessor who compares the policy with the current network diagram will find the mismatch quickly. Review the policy against the live environment before the assessor does, and confirm with your QSA how they expect evidence of that review to look. The second problem is roles held informally by one engineer. When one person quietly approves every rule change, nobody else can say who is accountable if a rule is wrong. Write a responsibilities record, such as a RACI matrix, that names who owns policy, who approves changes, who operates the controls and who reviews them, and confirm that each named person knows the role. A wiki with version history, such as XWiki, can hold the policy and its change record, and a permissions model in a tool like BookStack can separate who may edit procedures from who may only read them.
Which systems, teams and third parties 1.1 covers
Requirement 1.1 applies wherever network security controls protect or separate the cardholder data environment, so scope decisions set how much policy and role documentation you need. The cards below cover the components, teams and outside parties that the policy and role record must reach. Scope follows the CDE definition in the standard, not the size of your firewall estate.
NSC types inside and around the CDE
The standard uses the term network security controls (NSCs) for firewalls and other network security technologies that enforce policy at a network boundary. Your 1.1 policy should name every NSC type in use, including host-based filtering, routers with access lists and virtual firewall appliances, and state which CDE boundaries each one guards. An NSC that is not named in the procedures is easy to miss during review. Check that the inventory matches the network diagrams.
Wireless networks connected to the CDE
Any wireless network that connects to the CDE or can reach it falls within the NSC requirements, so wireless access points and their controllers must appear in the policy scope. Confirm whether guest, staff and point-of-sale wireless segments each have a documented owner. Wireless changes are often made by facilities or store teams, so the procedures should say who can alter them and who approves the change.
Cloud security groups and virtual controls
Cloud security groups, network access control lists, managed firewall services and virtual network appliances are NSCs when they filter traffic to CDE workloads. Their settings often live in a console managed by a cloud platform team rather than the network team. Your 1.1 documents should name the accounts, subscriptions or projects that hold them and the role responsible for each. Ask who can create a security group that touches the CDE.
Teams that operate or change NSCs
Network operations, security engineering, system administrators and application teams may each adjust NSC rules during an outage or release. The roles and responsibilities record must list each team, its permitted actions and the approver for each change type. Overlapping ownership between teams is a common reason assessors find roles that are documented but not understood. Interview a rule changer and confirm that they can describe their duties.
Outsourced firewall and cloud administrators
Managed security providers, hosting companies and cloud partners that administer NSCs or cloud security groups are part of the policy audience. The policy must reach their administrators, and the responsibility split must state which NSC tasks they own and which remain with your organization. Confirm how their staff receive policy updates and how their access is reviewed. Your service contract alone does not show that their staff know the policy.
Exceptions and emergency changes
Emergency rule changes, temporary exceptions and vendor-requested openings are the points where NSC governance most often breaks down. Document who may approve an exception, how long it may stay open and where the record of the change is kept. Include these paths in the procedures so that staff do not treat them as outside the policy. Ask for a sample of recent emergency changes and their approval records.
How a QSA tests 1.1.1 and 1.1.2
This table compares what a Qualified Security Assessor examines for each of the two sub-requirements under 1.1, the evidence usually requested and the gaps assessors most often record. Read it as a checklist of what to have ready before fieldwork, because a written policy alone rarely passes if people do not follow it or cannot name their role.
| Sub-requirement | How the assessor tests it | Evidence requested | Common findings |
|---|---|---|---|
| 1.1.1 Policies and procedures documented | Reads the network security control policy and operational procedures, checks the version and review dates, and confirms they cover every Requirement 1 activity. | Approved policy and procedure documents, revision history, and the review record showing they were updated after recent changes. | Procedures describe a process the team no longer follows, or they omit activities such as ruleset reviews or change approval. |
| 1.1.1 Procedures in use | Traces a recent real change, such as a firewall or NSC rule update, through the documented steps to confirm the steps were actually performed. | Change tickets, approval records, and review sign-offs for a sample of recent NSC changes. | Changes are made directly on devices with no ticket, or approvals are dated after the change was implemented. |
| 1.1.1 Known to affected parties | Interviews network, operations and security staff, and asks each to describe where the procedures live and which steps they own. | Training or acknowledgment records, and proof that procedures are published where affected staff can reach them. | Staff describe an older process, or contractors who administer NSCs have never seen the procedures. |
| 1.1.2 Roles and responsibilities documented | Reviews the written assignment of duties for Requirement 1 activities, such as ruleset approval, reviews and monitoring. | A roles and responsibilities record, such as a RACI matrix, that names functions or individuals for each Requirement 1 activity. | Responsibilities are described only in general terms, or the matrix names people who have left the organization. |
| 1.1.2 Roles assigned and understood | Interviews the people named in the record and asks them to explain what they are accountable for and who backs them up. | Job descriptions or role assignments, delegation records and evidence of coverage during absence. | The named owner does not recognize the responsibility, or no backup exists for approvals and reviews. |
| Overlap between 1.1.1 and 1.1.2 | Compares the procedures with the roles record to confirm every procedural step has an assigned owner. | Cross-referenced policy and RACI documents that point to the same activities and names. | Procedures assign steps to a team, but the roles record assigns the same step to nobody. |
Implementing 1.1 in the order an assessor will read it
This sequence moves from knowing which network security controls exist to a signed, published policy, named owners and trained staff, then keeps all of it current. Each step produces a record an assessor can examine and check against the people who run the controls.
Inventory network security controls and their owners
Start by listing every network security control (NSC) that touches the cardholder data environment, including firewalls, cloud security groups, routing filters and wireless boundary devices. For each one, record the platform, the location, the team that administers it and the business owner who accepts its risk. The output is an NSC inventory that matches your network and data-flow diagrams. You know this step is complete when every device or rule set in the scope boundary appears once, with a named owner, and nothing administered by an unknown party remains.
Draft the network security control policy
Write the policy that governs how NSCs are selected, configured, changed and reviewed, and state the rules that apply to the cardholder data environment. Keep it short enough that operators will actually read it, and link each statement to the procedure that carries it out. The output is a draft policy and a matching set of operational procedures covering routine administration, rule changes, emergency changes and periodic review. Check the draft against your inventory so that every control type has a procedure that describes how it is run.
Assign roles and responsibilities in a RACI matrix
Map each Requirement 1 activity to the people or teams responsible, accountable, consulted and informed. Cover rule approval, change implementation, log review, configuration backups and exception handling, and make sure each activity has exactly one accountable owner. Confirm the assignments with the people named, since the standard expects personnel to understand their duties and not just appear on a chart. The output is a roles and responsibilities record, usually a RACI matrix, with sign-off from the owners it names.
Approve and publish the policy and procedures
Route the policy and procedures to the executive or governance body that holds authority over information security, and record the approval with the date and approver's name. Publish the approved versions in the location where affected staff look for operational guidance, and retire earlier drafts so that only one current version is visible. The output is a signed policy, approved procedures and a publication record. An assessor will ask whether the documents in use match the approved versions, so the check is that the published copy and the signed copy are identical.
Train affected staff and collect acknowledgements
Brief everyone named in the RACI matrix and anyone who administers, changes or reviews NSCs on the policy and their specific procedures. Explain what they must do, when they must escalate and where the current documents live. Collect a written acknowledgement from each person. The output is a training record and a training acknowledgement list. You know this step is complete when every person on the roles record has an acknowledgement dated after the policy was approved, and any gaps are closed before the assessment begins.
Set the review cycle and change triggers
Define how often the policy, procedures and roles record are reviewed, and which events trigger an earlier review, such as a change of scope, a new payment channel, a reorganization or a new NSC platform. Assign the reviewer for each document and log each review, including the outcome even when nothing changed. The output is a review schedule, a review log and version history for each document. Confirm the chosen interval with your assessor or QSA, since the standard expects the documents to stay current but does not fix a single period for every organization.
How to keep policy and practice from drifting apart
A network security control policy that exists on paper but does not match how NSCs are actually changed is the most common way Requirement 1.1 fails in practice. Requirement 1.1.1 expects the policies and operational procedures to be kept up to date, in use and known to everyone who runs NSCs, so the test is not whether a document exists but whether the people administering firewalls and cloud security groups follow it today. Assessors usually check this by comparing the written procedure against a recent change record and asking the responsible staff to walk through it.
Build explicit triggers that force a procedure review instead of relying on memory. Useful triggers include commissioning a new NSC, opening a new cloud account or virtual network that touches the cardholder data environment, a change in the staff who own a control, and any incident that exposed a gap in the process. For each trigger, name the role that must confirm the procedure still holds and record the date of that confirmation. Ask your team to show you, for the last few changes, which trigger fired and where the review was recorded. If the answer is unclear, the drift has already started.
A versioned wiki or documentation platform makes that record defensible. Self-hosted tools such as XWiki keep every change under version control, recording what changed, when and by whom, and let reviewers compare any two versions or roll back. BookStack handles access through roles, so only designated owners can approve edits to the Requirement 1 pages while everyone else reads them. Confirm with your own platform team that edit history is retained for the full period an assessor will sample, and that approvals are stored with the page rather than in a chat thread. Treat the page history as a living record, since evidence for 1.1 is the accumulated trail of reviews, not a single policy signed once a year.
Evidence that passes a 1.1 review
An assessor testing 1.1 looks for two things: written documents that describe Requirement 1 controls, and proof that people use them. The cards below cover the artifacts to hold and the checks an assessor will run against the live environment, so the paper record matches what operators actually do.
Written NSC policy
The network security control policy states the rules for how NSCs are deployed, managed and changed across the cardholder data environment and its connections. Assessors examine it for scope, purpose and coverage of every NSC type in use, including cloud security groups and wireless boundaries. Confirm that the policy names the systems it governs and that it matches the current network diagrams, not the architecture from two years ago.
Operational procedures
Procedures turn the policy into steps: how a rule is requested, reviewed, approved, deployed, tested and removed, and how NSC alerts are handled. Assessors compare them with real tickets and change records. Check that each procedure names its inputs, its owner and the record it produces, so an operator can follow it without asking the author.
Roles and responsibilities record
A RACI matrix or equivalent table assigns each Requirement 1 activity to a named role, with one accountable owner per activity. Assessors interview the people listed and ask them to explain their duties. Keep the record tied to job roles rather than individuals, and confirm that every activity has a named accountable owner with a deputy for absence cover.
Approval and version history
Each policy and procedure needs a recorded approver, an effective date and a version number. Assessors check that the approved version is the one in use and that earlier versions are retained. Version control in the document system should show what changed, when and by whom, so you can answer questions about any past state of the rules.
Staff acknowledgements
Personnel who run or rely on NSCs should sign or electronically accept the current policy and procedures. Assessors sample staff and ask for their acknowledgement of the version in force. Keep acknowledgements linked to the version number, and rerun them after each material change so that the record shows who read which version, not only that a policy exists.
Dated review log
A review log records each scheduled and ad hoc review of the policies, procedures and roles, with the reviewer, the outcome and any changes made. Assessors look for evidence that reviews happen on a set cycle and that findings led to updates. Check that the log covers the gap between audits, because an empty log for a year is a common reason for a finding.
What meeting 1.1 costs in money and effort
Drafting the network security control policy and operational procedures is usually the largest one-time cost in Requirement 1.1. The work is done by people, not software: security staff write the policy, network engineers describe how rulesets are actually managed, and reviewers confirm the text matches practice. Roles design (the responsibility assignment for each Requirement 1 activity) is a smaller, related one-time task that often happens in the same workshops.
- Internal staff time: Security, network and platform staff spend hours writing and reviewing text. This is an internal cost, and it is often the one organizations underestimate.
- External drafting support: If you buy help, the fee depends on how many documents, environments and business units are in scope. Ask for it as a fixed deliverable.
- Roles workshops: Time for agreeing a RACI matrix across security, network, application and operations teams. Cross-team disagreement makes this phase longer.
- Review and approval: Time for management sign-off, which recurs each time the document changes.
- Rework from scope changes: Adding environments or connected services after drafting usually means revisiting both documents.
Ask the provider to state the number of documents, the number of workshops and who approves each deliverable.
Requirement 1.1.1 expects the policies and procedures to be known to all affected parties, so training is a real cost even though it is easy to overlook. The initial rollout is one-time, but onboarding new staff and handling role changes is recurring. Costs here are mostly staff hours, plus any paid course or materials.
- Initial briefings: One-time sessions for network, security and operations staff who run NSCs day to day.
- Role-specific training: Shorter sessions for application owners and change approvers who touch rulesets indirectly.
- Onboarding: A recurring cost, since every new administrator must read and acknowledge the procedures.
- Acknowledgement records: Light administrative effort to keep sign-off records that an assessor can examine.
- Paid training: Optional external courses, priced per seat or per cohort. Confirm whether the price includes materials and assessment.
When you request a quote, ask whether training is included, how many sessions are assumed and whether refresher training is priced separately.
Evidence upkeep is the recurring cost that most often grows over time. Requirement 1.1 is not met once; the policy, the procedures and the roles record must stay current and show that they are in use. Each review produces a dated record, and each change to a document needs a trace of who changed it and why.
- Periodic review: Staff time to review the policy and procedures on the schedule your organization sets and to record the outcome.
- Change tracking: Self-hosted wiki platforms such as XWiki keep version history of each page, so changes can be compared and rolled back. This removes the need for a separate document management tool for this purpose.
- Access administration: BookStack assigns abilities through roles and allows permissions to be set per shelf, book, chapter or page. Administrators must keep these settings aligned with the RACI matrix.
- Compliance tracking: CISO Assistant can hold assessment records against PCI DSS and other frameworks, but licensing and hosting effort depend on your deployment choice.
- Role changes: Each staff move requires an update to the roles record and sometimes to the procedures.
Ask how the provider will keep evidence current after handover and who owns that task.
Assessor time is a cost you pay to an independent party. A Qualified Security Assessor (QSA) examines documentation and interviews responsible personnel for Requirement 1.1, and the time depends on how well-organized your documents are and how many environments are in scope. Tool licence cost is the other variable. Self-hosted open-source wiki and documentation tools remove the licence line for the document store itself, but hosting, backup and administration still cost money.
- QSA or assessor time: Charged by the assessor, usually on the basis of the scope they agree. Clear documents and a ready roles record reduce the time they need to spend on this requirement.
- Preparation time: Internal staff time to gather documents, prepare interviewees and answer questions before the assessment.
- Licence spend removed: Self-hosted tools such as XWiki, BookStack and CISO Assistant have open-source licences, so there is no per-seat licence for the document store. Confirm any support contract or paid add-on separately.
- Hosting and backup: Infrastructure inside your own environment carries recurring cost, which should be included in the total.
- Independence: Your assessor cannot write the policy for you. Keep that work separate from assessment to avoid a conflict of interest.
Ask the assessor for a quote that states the assumed interviews, documents reviewed and number of days, and whether re-testing is included.
Open-source tools that hold 1.1 evidence
This table compares three open-source tools that can hold the documentation Requirement 1.1 expects: XWiki for versioned policy text, BookStack for role-scoped access to procedures, and CISO Assistant for mapping and assessment records. Read each row as a place to store evidence, not as a control that satisfies the requirement. The main takeaway is that the tool only proves what the organization puts into it and keeps current.
| Tool | Evidence supported | How it is used for 1.1 | License caveat |
|---|---|---|---|
| XWiki | Version history of the network security control policy and operational procedures | Keep each policy and procedure as a versioned page so an assessor can see what changed, when and by whom, and roll back if a draft was wrong | LGPL-2.1-or-later; confirm obligations with counsel before modifying and redistributing |
| BookStack | Role-based access showing who can view, edit and approve Requirement 1 documentation | Organize NSC policies, procedures and the roles record into shelves and books, then assign roles so responsible staff can reach the content they must follow | MIT; confirm role configuration matches your access model and document it |
| CISO Assistant | Mapping of Requirement 1.1 to assessment records, owners and review status | Link 1.1.1 and 1.1.2 to stored evidence, record assessor findings and track ownership of each requirement | AGPL-3.0-only; confirm obligations if you run a modified hosted version for users |
| Tool limitation (all three) | None on their own; evidence depends on content | Assessors still examine the documents and interview staff, so the tool must reflect how the network is actually run | Confirm each tool's current version and features in your environment before relying on them |
Who writes, approves and checks the 1.1 evidence
Your organization owns Requirement 1.1 in full. The network security control policy and operational procedures must reflect how your environment actually runs, and the people named in the roles record must accept those responsibilities. An assessor will interview these people, so the answers they give have to match the documents. Ownership cannot be handed to an outside firm, even when a partner drafts the text.
- Policy approval: Senior management or the designated governance body should approve the network security control policy and record that approval with a date and version.
- Procedure ownership: Named teams should own each operational procedure, such as change requests, ruleset reviews and log checks.
- Roles record: A RACI matrix or equivalent should name who is responsible, accountable, consulted and informed for each Requirement 1 activity.
- Staff awareness: Affected staff should know the documents exist and where to find them, which the standard expects for policies in use.
- Ongoing upkeep: Someone must keep the documents current after every change to the environment.
Before the assessment, confirm that each named owner can explain their duties without reading from the document.
An implementation partner such as DeployOpen can prepare the documentation and the structure of the evidence. This work is usually outsourced because it is time-consuming: drafting the policy and procedures, building a wiki or document system with version history, setting up the roles matrix and mapping each document to the sub-requirements. The partner works from your environment and your decisions. It does not decide the policy or accept the roles on your behalf.
- Draft preparation: The partner can draft policy and procedure text for your review, based on the systems and processes you describe.
- Documentation build-out: The partner can set up an internal knowledge base with version control, access rights and a clear document index. The XWiki blog on document version control describes that kind of record-keeping.
- Evidence structure: The partner can organize files so an assessor can find the policy, procedures and roles record quickly.
- Gap review: The partner can compare the drafts against the sub-requirement wording and flag missing owners or outdated steps.
- Hand-over: The partner should train your owners to maintain the documents after the engagement ends.
DeployOpen prepares documentation and evidence. It does not issue reports, attestations or certifications. Ask any partner to confirm this in the written scope.
A Qualified Security Assessor (QSA) tests Requirement 1.1 independently and records the result in the Report on Compliance. Under the standard's assessment approach, the QSA examines the documentation and interviews the responsible personnel. The QSA's conclusions belong to the QSA, and the organization cannot write them.
- Document examination: The QSA reviews whether the policy and procedures are current, approved, in use and known to the affected parties.
- Interviews: The QSA speaks with the named owners to confirm they understand their roles.
- Independence line: A consultant that drafted the documents can still work with the QSA, but the QSA must not design the controls it is assessing as part of the same engagement.
- Scope agreement: The QSA and your organization should agree the scope of Requirement 1 before testing begins.
- Attestation: Only the QSA's report and the Attestation of Compliance carry assessment weight. A certificate alone is not accepted as validation.
Ask your QSA early which documents and interviews they expect, and confirm the evidence format with them before you build anything.
Where 1.1 usually fails and how to close each gap
Requirement 1.1 is judged on paperwork that is current, known to the people who run the network, and backed by named owners. Most failures come from documents that stopped matching the network, roles that depend on one person, and procedures that were never formally adopted. The cards below cover five gaps an assessor is likely to find and the action that closes each one.
Policies describing retired networks
The network security control policy often still describes segments, firewall groups and vendor tools that were decommissioned during a migration or cloud move. Assessors test 1.1.1 by comparing the written procedures with the live environment, so a policy that names a retired zone fails even if the controls themselves work. Close the gap by reconciling every policy statement against the current network and data-flow diagrams, then recording the date of that review in the document history. Check that each named segment still exists.
Roles held by one person
When a single engineer approves firewall changes, reviews their own rule requests and holds the only administrator login, the responsibilities required by 1.1.2 are assigned on paper but not in practice. Assessors look for a roles and responsibilities record, usually a RACI matrix, that shows who owns each Requirement 1 activity and who backs them up. Close the gap by naming a primary and alternate owner for each activity and confirming that the people named understand their duties. Separate the approver from the implementer wherever staffing allows.
Procedures never formally adopted
Operational procedures for rule requests, emergency changes and log review are sometimes drafted by a team but never approved by management or circulated. Under 1.1.1 the procedures must be documented, in use and known to all affected parties, so an unsigned draft shows that the requirement is not yet met. Close the gap by obtaining written approval from the accountable manager, publishing the approved version in the team's knowledge base, and keeping the approval record with the document. An unapproved draft is not evidence of a procedure in use.
No training record
Assessors interview the people responsible for network security controls and expect them to explain their duties in their own words. If the team has never been briefed on the current policy, or the briefing left no record, the interview tends to expose the gap quickly. Close the gap by running a documented briefing on the policy and procedures, recording attendance and the version reviewed, and repeating it when documents change. Keep the attendance record with the policy version it covers.
No review trigger on change
Policies are often reviewed on an annual calendar date, while network changes happen weekly. A new cloud subnet, a vendor onboarding or a change to a payment flow can leave the documents wrong for months before anyone notices. Close the gap by adding a documented trigger to the change process so that any change to NSC rules, network topology or responsibilities also prompts a review of the affected policy, procedure or role assignment. Make the review a required step in the change ticket.
Questions buyers ask about 1.1 cost, effort and outside help
How much effort does requirement 1.1 take to meet?
Requirement 1.1 is mostly documentation and governance, so the effort is smaller than the technical work in Requirements 1.2 to 1.5, but it is not small. Two sub-requirements sit underneath it: one for documented, current network security control policies and operational procedures that people actually use, and one for documented, assigned and understood roles and responsibilities. The effort depends on how many network security control platforms you run, how many teams touch them, and whether a written policy already exists. Expect a one-time drafting and approval effort, followed by recurring reviews to keep the documents current. Ask any provider to estimate effort against a written list of the documents and roles in your environment, not against a generic template.
Can we meet requirement 1.1 in-house?
Yes, in most organizations the owner of requirement 1.1 is internal. The organization owns its controls, so its policies, procedures and role assignments must be written, approved and used by its own staff. What an internal team needs is a clear view of who operates each network security control, a current inventory of the platforms involved, and a way to keep documents versioned and reviewed. Internal teams often struggle with the roles sub-requirement, because responsibilities are split between network, security, operations and the people who approve changes. A RACI matrix, reviewed with the people named in it, usually closes that gap. Outside help is optional and usually targets drafting, gap review or evidence preparation.
What does an implementation partner need from our team?
A partner needs access to the people and records that describe how your network security controls really run. In practice that means named owners for each network security control platform, current network and data-flow diagrams, existing change tickets, and any policy or procedure documents you already use. The partner also needs decision-makers who can approve the policy and confirm the roles, because a document nobody has agreed to will not survive an assessment. Expect to provide interview time with the people who run the controls, since assessors test 1.1 by examining documents and interviewing responsible personnel. Agree these inputs in the written scope before work starts so the engagement does not stall on missing records.
How long does requirement 1.1 take to complete?
No researched timeline is available for this requirement, so any duration you hear should be treated as an estimate to verify. The elapsed time depends on how quickly your organization can agree on the policy, confirm roles with the people named in them, and collect the existing documents. Organizations with a mature policy library often finish faster than those drafting from scratch. Ask a provider for a timeline tied to a written scope, the named deliverables and the review cycle your approvers can meet. Also confirm with your assessor or acquirer when the evidence must be ready, since that date usually drives the schedule more than the drafting work does.
Can our PCI auditor help write the network security control policy?
No. A Qualified Security Assessor or other independent assessor must remain independent of the work it later validates, so an assessor should not write your policy, design your roles or prepare the evidence it will test. The assessor's job is to examine what you have, test whether it is in use, and report on it. Writing the policy is the organization's responsibility, and an implementation partner can help prepare the documents and evidence while keeping the assessor independent. When you select providers, separate the people who prepare documents from the firm that issues the Report on Compliance or Self-Assessment Questionnaire and its Attestation of Compliance.
Who owns the final evidence for requirement 1.1?
Your organization owns the evidence, and the signed Attestation of Compliance comes from the assessor, not from you or your partner. The evidence for 1.1 is the written network security control policy and procedures, plus a roles and responsibilities record such as a RACI matrix, along with proof that people know the documents and that they are reviewed. Your team must keep these records current, store them under version control, and produce them on request. An implementation partner can prepare the documents and help organize the record, but the organization is accountable for their accuracy and use. Confirm the evidence list with your assessor early so there are no surprises at the audit.
Which tools can host the 1.1 policy documents and version history?
Several self-hosted open-source wikis can hold policy and procedure documents with version history, which makes the evidence easier to maintain. XWiki keeps every page change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack lets you assign user abilities through roles and override permissions per role at the shelf, book, chapter or page level, which helps separate who edits policy from who reads it. A compliance platform such as CISO Assistant ships PCI DSS as one of its frameworks and can track assessment work against it. Tool choice does not make a policy compliant, so confirm with your assessor which records they expect to see.
How DeployOpen prepares 1.1 evidence
DeployOpen works on Requirement 1.1 as a set of documents and role assignments that have to be accurate, in use and understood by the people who run network security controls. We prepare the policies, procedures and roles record inside your own infrastructure and tooling, while your organization owns the controls and an independent assessor decides whether the evidence meets the standard.
How we scope
- Engagements are fixed-scope, with the policy set, procedures and roles record agreed in writing before work starts.
- We confirm which network security control processes apply to your cardholder data environment and which teams operate them.
- The written scope names the documents, owners, review cycle and interviews that will serve as 1.1 evidence for your assessor.
How we build
- We draft the Requirement 1 network security control policy and operational procedures to match how your systems actually run.
- We build a roles and responsibilities record, such as a RACI matrix, and confirm each named owner accepts their duties.
- We host the documents in a version-controlled wiki or knowledge base in your environment, so every change is traceable.
How we hand over
- You receive the approved policy, procedures and roles record, with version history and a clear owner for each document.
- We walk responsible personnel through the documents so they can explain their duties during an assessor interview.
- We provide a list of the evidence files and their locations, ready for your QSA or internal assessor to examine.
How we support
- Ongoing support, upgrades and reviews can be arranged as a retainer after the initial handover is complete.
- We help you set a review cadence so the policies and roles stay current as staff, systems and network designs change.
- Questions about how an assessor will test 1.1 are answered with your assessor, since only they issue the validation.
