How a PCI DSS 12.2 acceptable use policy gets assessed
An assessor will ask for the acceptable use policy and then ask for proof that staff follow it. Requirement 12.2 has one sub-requirement, 12.2.1, which asks that acceptable use policies for end-user technologies be documented, implemented and explicitly approved by authorized parties. The policy must state what each technology may be used for, and the organization must keep a list of company-approved hardware and software. In practice the assessor reads the policy, checks that its approval record is signed by someone with authority, compares the approved list against the devices and applications actually in use, and interviews a sample of staff to confirm they know the rules. The standard's note names the technologies in scope: remote access and wireless, laptops, tablets, mobile phones, removable electronic media, email and internet use. Confirm with your QSA which of these apply to your cardholder data environment (CDE) before you draft the policy, because the examples are not a checklist you can skip.
The risk behind 12.2.1 is unmanaged end-user technology that reaches the CDE. A laptop with an unapproved remote access tool, a personal phone used for email with card data in it, or a USB drive copied from a payment workstation can all bypass controls that protect the systems themselves. The policy is the rule that lets staff and administrators tell an allowed action from a risky one. Two things make it hard to keep. First, the policy has to describe how people really work, including remote support, shared workstations and bring-your-own devices where those exist, rather than an ideal they do not follow. Second, the approved hardware and software list goes stale as teams adopt new tools, so someone must own its updates and check it against inventory on a schedule. Ask your team who approves additions, how requests are recorded, and where the current list is stored, because the assessor will ask the same questions.
Evidence for this sub-requirement is mostly documentation and records, so the choice of where those documents live matters. A wiki or knowledge base with version control lets you show the policy version in force on a given date, who changed it and when, and the approval history. Role-based permissions limit who can edit the policy and the approved list while leaving it readable to all staff. Self-hosted open-source platforms such as XWiki and BookStack can hold these records inside your own infrastructure, but you should confirm that each platform's version history and access controls meet your evidence needs before you rely on them. Link the policy to the security awareness training required under 12.6.3.2, since the same acceptable use content must be taught. Your assessor will look for that connection, so plan for it from the start.
Which end-user technologies and teams fall under the acceptable use policy
Requirement 12.2.1 applies to end-user technologies, and the list is set by where each technology touches the cardholder data environment (CDE). Start from the scope you have documented, then name every device, service and group of people that can reach it.
Remote access and wireless
Remote access tools and wireless networks are the most common ways into a CDE from outside the building. For each one, record who may connect, from which devices, over which protocols, and whether multi-factor authentication applies. Check that the wireless networks in your inventory match what the policy names, including guest and contractor networks that share infrastructure with in-scope segments. Any remote access path that reaches the CDE belongs in the policy's approved list.
Laptops, tablets and mobile phones
Assessors look at whether company-owned and personally owned devices that open payment systems, email with card data, or admin consoles are named and governed. Ask whether any employee device stores, displays or can reach CDE data, and whether a staff member can use a personal phone to access an admin portal. Each device class you allow should appear on the approved hardware and software list with its permitted uses.
Removable electronic media
USB drives, external disks and similar media can carry card data out of a CDE without any network trace. The policy should state whether removable media is allowed at all, and if it is, which approved products are permitted and for what purpose. Confirm with your environment owners whether these devices are blocked, monitored or only permitted for specific tasks, since the answer changes what the policy must name.
Email and internet usage
Email and web browsing are the end-user channels most likely to meet phishing, malicious downloads and accidental data sharing. Decide whether staff with CDE access may send or receive card data by email, which websites and file-sharing services are acceptable, and how personal accounts are handled on company devices. Confirm these rules with the owners of your email and web filtering controls so the written policy reflects what the systems actually enforce.
Staff, contractors and administrators
The policy applies to everyone who uses in-scope end-user technologies, not only employees. Contractors, temporary staff, and administrators who hold elevated access to CDE systems should each be named as covered groups, with any different rules for privileged work spelled out. Confirm that contractor agreements require acceptance of the policy before access is granted, and that administrators understand which tools they may use for support work.
Scope changes update the list
Each change to the CDE, such as a new payment channel, a cloud migration or a new remote support vendor, can add or remove technologies the policy must name. Tie the approved product list to your documented scope and review it whenever that scope changes. Ask your assessor which scope documentation they will request, because the devices and services in the policy should match it exactly.
How an assessor tests 12.2.1
This table walks through what an assessor examines for requirement 12.2.1, from the policy document and its approval record to the approved product list and proof that personnel were told about the policy. Read each row as a test step, the evidence it usually produces, and the gap that most often leads to a finding.
| Test area | What the assessor checks | Evidence usually requested | Common finding |
|---|---|---|---|
| Policy document | The acceptable use policy exists, is documented and covers the end-user technologies named in the standard | Current policy text with version history and a list of covered technologies | Policy omits remote access or mobile phones |
| Approval record | An authorized party explicitly approved the policy | Signed approval, meeting minutes or workflow record naming the approver and date | Policy has no named approver or approval date |
| Acceptable uses | Each end-user technology has stated permitted and prohibited uses | Section-by-section use rules for laptops, phones, removable media, email and internet | Uses are generic and do not address the technologies in the environment |
| Approved hardware and software list | The list matches the devices and applications actually in use in the environment | Approved list export, asset inventory and a sample reconciliation between the two | Approved list does not match devices or software found in use |
| Remote access and wireless | Rules for remote access and wireless technologies are defined and tied to approval | Remote access standard, VPN or access tool approvals, wireless use rules | Remote access exists in practice with no documented approval |
| User notification | Personnel are told about the policy and acknowledge it | Acknowledgment records, training content covering 12.2.1 topics, distribution logs | Acknowledgments are missing for contractors or new staff |
| Currency | The policy and list are kept current as technologies change | Review dates, change log and evidence of updates after new devices or services | Policy was written once and not revised when the environment changed |
Steps to write, approve and enforce the policy
The sequence turns 12.2.1 from a document on a shelf into a policy that names the technologies in use, states who may approve them, and is kept current and taught to staff. Each step produces a record an assessor can sample.
Inventory end-user technologies in scope
Start by listing every end-user technology that personnel use with access to, or near, the cardholder data environment. Cover the categories the SAQ D note names: remote access and wireless technologies, laptops, tablets, mobile phones, removable electronic media, email and internet usage. Assign each entry an owner and note whether it is company-issued or personally owned. The output is a dated inventory that the policy owner signs off, and it becomes the reference for every later step.
Draft acceptable uses for each technology
For each inventory entry, write the uses that are permitted, the uses that are prohibited, and the conditions attached, such as required authentication for remote access or restrictions on copying cardholder data to removable media. Keep the rules specific enough that a user can tell whether an action is allowed. Have the security lead and the owners of affected systems review the draft. The output is a draft policy with one section per technology category.
Obtain explicit approval from an authorized party
Requirement 12.2.1 expects explicit approval by parties the organization has authorized to approve. Confirm in your own policy who holds that authority, typically a named executive or the security governance body, and record the approval against the specific version of the policy. Ask your assessor early which approver roles they will accept. The output is a signed approval record that shows the approver, the date and the policy version approved.
Build the approved hardware and software list
Turn the approved technologies into a list of company-approved hardware and software, with the model or version, the permitted use, the owner and the review status. Include approved mobile device management, collaboration tools and removable media controls where they are used. Anything not on the list should follow a documented request path. The output is the approved product list, referenced from the policy and kept in a system of record your team can export for assessors.
Publish and version the policy
Publish the approved policy in the location personnel already use, and make it discoverable from onboarding and the security intranet. Store each version with its change history so you can show what changed, when and who approved it. A wiki with version control, or a document system with role-based access, can hold both the policy and its history. Confirm that only authorized editors can change the approved text. The output is a published policy with a retrievable version history matching the approval records.
Link the policy to security awareness training
Requirement 12.6.3.2 expects security awareness training to cover acceptable use of the end-user technologies named in 12.2.1. Map each acceptable use rule to a training module or to a knowledge check, and record which staff completed it. Update the training whenever the policy or the approved list changes. The output is a training map that connects each policy section to the lesson that teaches it, plus completion records for personnel.
Set a review routine and enforce the policy
Define who reviews the policy and approved list, what triggers an out-of-cycle review, such as a new device class or a change in remote access, and how exceptions are granted and expired. Record each review, even when no change is made, and log violations and how they were handled. Confirm the review frequency against the current text of the standard and your assessor's expectations, since that wording is not reproduced here. The output is a review log, an exception register and a violation record that together show the policy is enforced in practice.
Evidence that satisfies 12.2.1 and how to keep it current
An assessor testing Requirement 12.2.1 looks for a policy that is documented, approved, implemented and kept current, not a document that was written once. The cards below cover the artifacts that prove each part of that test and the routine that keeps them accurate between assessments. The organization owns this evidence; an implementation partner can help structure it, and only the QSA or assessor decides whether it is sufficient.
Versioned acceptable use policy
The policy document itself, with a change history that shows what changed, when and by whom. Assessors check that the version in force matches the version users were told about. Store the policy in a wiki or document system that keeps every revision and allows comparing or restoring earlier versions, such as XWiki, which records each change and its author. Confirm that retired versions stay retrievable for the assessment period.
Signed approval by authorized parties
Requirement 12.2.1 expects explicit approval by an authorized party, so keep a dated record of who approved each version of the policy and in what role. A signed approval record, meeting minutes or a ticket with an approver's sign-off are all acceptable forms if the approver is clearly authorized. Check that approval is repeated when the policy changes materially, not only at first publication.
Approved hardware and software list
The standard expects a list of company-approved hardware and software for end-user devices. Keep it as a controlled list with an owner, a version number and a date. Each entry should show the product, the version or model permitted, and the approved uses. Any addition or removal goes through a documented request that records the requester, the reviewer, the decision and the effective date, so the list at any past date can be reconstructed.
End-user technology inventory
Assessors compare the policy against what is actually deployed. Maintain an inventory of end-user technologies in scope: remote access tools, wireless networks, laptops, tablets, mobile phones, removable media, email and internet services. Reconcile the inventory with the approved list at least as often as the list changes, and record any device or service found outside the approved list along with its remediation or exception. Ask your QSA which inventory sources they will accept.
Training records covering acceptable use
Requirement 12.6.3.2 links security awareness training to the acceptable use rules in 12.2.1. Keep training materials, attendance or completion records, and the dates each cohort was trained. The records should show that acceptable use content is included, not only general security topics. When the policy changes, record which audience received the update and how quickly, so the training record matches the policy version in force.
Personnel acknowledgments
Collect a signed or electronically recorded acknowledgment from each person covered by the policy, including contractors who use company end-user technology. Link each acknowledgment to the policy version it covers, because an acknowledgment of an outdated version does not show current understanding. Set a process for new hires and for re-acknowledgment after material changes, and check the population against the directory of active accounts at each review.
What meeting 12.2.1 costs in money and effort
Meeting 12.2.1 is mostly internal time, with a few outside costs layered on top. Your own staff draft the acceptable use policy, maintain the approved hardware and software list, and keep the policy aligned with how people really work. Legal or HR reviews the wording on monitoring, personal devices and disciplinary action. Documentation tooling carries a license or hosting cost if you do not already run a wiki or policy platform. An assessor, either a Qualified Security Assessor for a Report on Compliance or the reviewer of a Self-Assessment Questionnaire, spends time sampling evidence. Outside consultants are optional and are paid for the work they do, not for the assessment itself.
- Internal security or compliance staff: draft, approve, and maintain the policy and the approved product list.
- Legal and HR: review monitoring notices, personal device terms, and enforcement language.
- Platform or IT teams: supply the device, software, and remote access inventory the policy must reference.
- Documentation tooling: a wiki or policy system, whether licensed commercially or self-hosted by your team.
- Assessor time: sampling of the policy, approvals, and the list during the validation.
When you request a quote, ask who performs each line item and whether the figure covers drafting, review, or only advisory time.
The first pass carries most of the effort. You must write a policy that names the end-user technologies in scope, state who authorizes their use, describe acceptable and prohibited uses, and build an approved hardware and software list. If you have no existing policy, this is a full drafting exercise across several departments. If you already have an acceptable use policy from an ISO or HR program, the work is mainly gap analysis against the 12.2.1 elements. Building the first inventory of laptops, phones, removable media, remote access tools, wireless, email, and internet services is often the largest single task, because it depends on how well your asset records already match reality.
- Policy drafting: writing acceptable uses for each technology category named in the SAQ D note.
- Approval chain: documenting which authorized parties sign off, and recording that approval.
- Initial approved list: a first inventory of permitted hardware and software, reconciled with asset management.
- Gap review: comparing an existing policy with the 12.2.1 elements, if one already exists.
- Rollout: communicating the policy and capturing initial acknowledgments for the awareness program.
Ask the provider to separate drafting from inventory reconciliation, since the second often expands once discrepancies surface.
After the first version, cost shifts to upkeep. The policy must stay documented and implemented, so it needs regular review, updates when technologies change, and a working approval path for new devices or software. The approved list needs continuous maintenance because staff adopt tools faster than policies are updated. Training content on acceptable use must be refreshed, since Requirement 12.6.3.2 ties awareness training to the 12.2.1 policy. Assessors check that the policy matches current practice in each validation cycle, so recurring evidence collection is a standing task rather than a one-off effort.
- Annual policy review: confirming the wording, roles, and technology categories remain accurate.
- List upkeep: adding, retiring, and approving hardware and software requests.
- Training refresh: updating acceptable use content in the awareness program.
- Exception handling: reviewing requests that fall outside the approved list.
- Evidence collection: keeping approvals and list changes available for assessor sampling.
Ask whether any retainer or support arrangement covers these recurring tasks and what level of effort it assumes.
Several factors push effort up or down. The number of device types and deployment models is the strongest driver: a fleet of company laptops with a few mobile devices is far simpler than a mix of personal devices, contractor equipment, kiosks, and multiple remote access methods. Whether you already have a policy shapes the drafting effort. The maturity of your asset inventory determines how quickly the approved list can be built. Organizational spread matters too, since each business unit that adopts different tools adds approval work. Finally, the degree of automation in your environment, such as centralized software deployment or mobile device management, reduces manual list maintenance. These are qualitative drivers. Confirm how they apply to your environment before estimating effort internally.
- Device and technology mix: more categories and personal devices mean more acceptable use rules.
- Existing policy: a current document shortens drafting and review.
- Asset inventory maturity: accurate records make the approved list faster to build.
- Number of business units: each adds approvals and exceptions to manage.
- Automation: centralized software and device management lowers upkeep.
In a quote, ask which of these drivers the estimate assumes and what would change the scope.
Which self-hosted tools keep the policy and its evidence in order
This table compares two self-hosted documentation platforms against the evidence needs of Requirement 12.2.1, namely version history, approval records and role-based editing. Read each row as a question to put to the tool and to your own retention rules before you choose one.
| Capability | XWiki | BookStack |
|---|---|---|
| Version history of policy pages | Every page change is kept under version control, recording what changed, when and by whom | Confirm how page revisions are retained and whether they meet your evidence retention period |
| Comparing and restoring versions | Users can compare any two versions and roll back to an earlier version | Confirm available revision comparison and restore options in your installed version |
| Role-based editing permissions | Confirm role and rights model against your approval workflow in your installed version | User abilities come from assigned roles, overridable per shelf, book, chapter or page |
| Approval record for acceptable use policies | Not a built-in approval step; record approvals in the page or a linked workflow you define | Not a built-in approval step; record approvals in the page or a linked workflow you define |
| License | LGPL-2.1-or-later; confirm obligations if you modify and distribute the software | MIT; permissive license, confirm terms with your legal team |
| Fit for approved product lists | Suits structured pages and tables that list approved hardware and software | Suits book and chapter structure for policy sets, with page-level lists |
| Retention of version history | Confirm backup and retention settings so history survives upgrades and migrations | Confirm backup and retention settings so history survives upgrades and migrations |
Who writes the policy, who approves it and who tests it
Requirement 12.2.1 expects the acceptable use policy to be explicitly approved by authorized parties. That approval is a business decision, so it has to come from people inside your organization who have the authority to accept the risk of the permitted uses. Your team decides which end-user technologies are allowed, which uses are acceptable, and which hardware and software appear on the company-approved list. An assessor will ask who signed off each of these and when, so the approval trail must exist before the assessment starts.
- Named approvers: Record which role or individual authorized the policy and each later revision, and keep the signed or system-recorded approval.
- Owned approved list: The approved hardware and software list belongs to a named function, such as IT asset management or the security team, with a defined update process.
- Decision on exceptions: Your team decides how exceptions are requested, who may grant them and how long they last.
- Acceptable use decisions: Choices such as whether personal phones may access email or whether removable media is permitted are business and risk decisions, not vendor defaults.
- Annual review: Schedule the review and keep the record that it happened.
Before the assessment, confirm that you can name the approver for every version of the policy and show where the approved list is maintained.
An implementation partner can do much of the preparation work, provided the partner's role is limited to producing material your team reviews and adopts. A partner can draft the acceptable use policy from your existing security policy, build the inventory of end-user technologies in use, configure the wiki or documentation system that holds the policy with version history, and assemble the evidence package. The partner does not approve the policy on your behalf and does not decide what is acceptable.
- Policy drafting: Produce a draft that maps each end-user technology named in the standard's guidance to a stated acceptable use, for your review.
- Inventory build: Compile an inventory of laptops, phones, removable media, remote access and wireless tools from asset and directory data, then flag gaps for your team to resolve.
- Documentation system setup: Configure a self-hosted wiki, such as XWiki with its page version control, so that every change records what changed, when and by whom.
- Access configuration: Set up roles so that editing the policy is limited to the policy owners, for example through BookStack role permissions.
- Evidence packaging: Assemble approval records, version history and the approved list into a folder that your team can hand to the assessor.
Confirm in writing which of these tasks are in the agreed scope and which remain with your staff.
Only an independent QSA or assessor tests the policy and issues the Report on Compliance or the Attestation of Compliance for the assessed entity. The assessor samples the approved policy, checks that it covers the required end-user technologies, reviews approval records, and compares the approved list with systems observed during testing. Your organization owns the result of the assessment, and the assessor is the party that states whether the requirement is met.
- Sampling evidence: The assessor selects versions and approvals to confirm the policy was in force during the assessment period.
- Comparing the list: The assessor checks whether devices and software seen in the environment appear on the approved list.
- Judging the wording: The assessor decides whether the stated acceptable uses are specific enough to be enforced.
- Issuing the report: Only the assessor completes the official PCI SSC templates and signs the attestation.
- Partner separation: The partner that built the inventory or drafted the policy should not be the party that tests it, since that would mean reviewing its own work.
Ask your assessor early which evidence they will request, and confirm that your implementation partner is not providing the assessment.
Where organizations fall short on acceptable use
Most acceptable use gaps are not missing documents. They are policies that do not match the devices, channels and people they are meant to govern, or evidence that cannot show the policy was approved and followed. The cards below cover the gaps assessors most often find under Requirement 12.2 and the steps that close each one.
Generic policy with no approval record
A policy copied from a template, with no named approver and no date of approval, does not satisfy the explicit approval element of 12.2.1. Check that the document names the authorized party who approved it, that the approval is dated, and that the approval is retained alongside the policy. Assessors look for this record first, so keep it in the same location as the policy text.
Approved list lags device purchases
The approved hardware and software list is only useful if it reflects what people actually use. Laptops, tablets and phones bought outside a refresh cycle often never reach the list. Reconcile the list against procurement records and asset inventory at a set interval, and document who approves each addition or removal.
Removable media and personal phones unmentioned
Many policies cover laptops and email but say nothing about USB drives, external disks or personally owned phones used for work email. 12.2.1 names removable electronic media and mobile phones among the end-user technologies to address. Add an explicit acceptable use statement for each one, including whether personal devices may access company email and what controls apply.
Training that ignores the policy
Security awareness content often covers phishing and passwords but not the acceptable use rules themselves. Requirement 12.6.3.2 expects training to cover acceptable use of the technologies named in 12.2.1. Map each acceptable use statement to a training module, and record completion so the link between policy and training can be shown to an assessor.
Remote access and wireless left out
Remote access and wireless technologies are named in the SAQ D note to 12.2.1, yet policies often treat them as IT configuration rather than end-user rules. Define who may connect remotely, from which devices, and which wireless networks staff may join. State these as acceptable uses so that the policy governs user behavior, not only administrator settings.
No version history or change record
Without version control, nobody can show which wording was in force on a given date or who changed it. Keep the policy in a wiki or document system that records each change with its author and date, and retain prior versions. Confirm with your assessor which evidence period they will review and make sure the history covers it.
Questions buyers ask about PCI DSS 12.2
Can our own team write a PCI DSS 12.2 acceptable use policy?
Yes, in most organizations the policy is written by the security or compliance team with input from IT, HR and legal, because the organization owns its policies. Requirement 12.2.1 expects a documented policy that is actually implemented, so the work is more than drafting text. Someone must decide which end-user technologies are covered, who approves exceptions, which hardware and software are approved, and how staff confirm they have read the rules. Your team also needs to be able to show that the policy matches how laptops, phones, removable media, email and remote access are really configured. If your staff have not yet inventoried these technologies, that inventory is the first task to plan. An independent assessor will test the policy against actual practice, not just its wording.
What does a 12.2 policy need from our staff?
It needs a small group with clear roles and enough time to make decisions. Typically this includes a policy owner, an approver with authority to grant exceptions, IT staff who can describe the device and access setup, and HR or legal reviewers for employee consent and disciplinary wording. Security awareness owners also need to carry the policy into training, because Requirement 12.6.3.2 expects training to cover acceptable use of end-user technologies. Ask who will maintain the approved product lists and how often they are reviewed, since those lists must stay accurate after the first release.
How long does it take to put a 12.2 policy in place?
No duration is fixed by PCI DSS, so the timeline depends on how much of the work already exists. A team with a current device inventory, an approval process and an existing acceptable use policy may need far less time than one starting from nothing. The main variables are the number of end-user technologies in scope, the number of approvers involved, and how many systems must be checked against the approved lists. Confirm the expected timeline in writing with whoever is doing the work, and ask what must be finished before the assessor reviews the evidence.
What drives the effort of meeting Requirement 12.2.1?
Effort rises with the number and variety of devices and channels in your environment. Remote access, wireless, laptops, tablets, mobile phones, removable media, email and internet use each need an acceptable use statement, an approval path and a check that technical settings match the rule. Organizations with mixed ownership models, such as bring-your-own-device or contractor laptops, carry more work. Effort also grows when approved software lists are not maintained centrally, or when exceptions are granted informally. Reducing scope to fewer device types and documenting one approval process usually lowers effort the most.
Does an SAQ or a ROC change what 12.2 requires?
The requirement itself does not change, but the depth of evidence an assessor expects does. Under a Self-Assessment Questionnaire, the organization answers the questions and signs the Attestation of Compliance, and it must still hold the supporting documents. Under a Report on Compliance, a Qualified Security Assessor tests the policy, the approvals and the technical configuration, then reports the results. Which SAQ or whether a ROC applies is decided by the payment brands and your acquirer, so confirm that before planning. Whichever path applies, the policy, approval records and training evidence must exist and match.
When is outside help worth paying for on 12.2?
Outside help is worth considering when the internal team lacks an accurate device inventory, has no clear approver for exceptions, or cannot connect policy text to real configurations. An implementation partner such as DeployOpen can prepare systems, document approved lists and build the evidence trail, under a written, fixed scope. It cannot issue the assessment report or attestation, because only an independent QSA or the relevant assessor does that. Keep the advisor separate from the assessor where possible, so the same party does not design the controls and then judge them. Ask any provider to define deliverables, responsibilities and exclusions in writing before work starts.
What evidence will an assessor ask for under 12.2?
Assessors usually ask for the signed and dated policy, proof that it was approved by an authorized party, the list of approved hardware and software, and records showing that staff received it. They may also sample devices and compare their configuration against the stated acceptable uses. Version history helps here, because it shows when the policy changed and who approved each change. Wiki platforms such as XWiki keep page version history and can compare or roll back versions, and BookStack assigns permissions by role, which can support controlled editing of the policy. Confirm with your assessor which records they accept before you build the evidence set.
How DeployOpen prepares 12.2 evidence for your assessment
DeployOpen helps you prepare the documented acceptable use policies, approval records and approved product lists that Requirement 12.2 expects, inside your own environment. Your organization owns the policy and its approvals, and an independent QSA decides whether the evidence meets the requirement.
How we scope
- Confirm which end-user technologies are in use, such as remote access, wireless, laptops, phones, removable media, email and internet.
- Agree which business units, locations and personnel the policies must cover for the cardholder data environment.
- Record the scope, deliverables and timeline in writing before work starts, since engagements are fixed-scope.
How we build
- Draft acceptable use policy sections for each end-user technology in scope, with explicit approval by authorized parties.
- Set up an approved hardware and software list that maps to your asset inventory and records who approved each entry.
- Configure the documentation platform so each policy version, approval and change is tracked, and tie it to 12.6.3.2 training content.
How we hand over
- Deliver the policy set, approval records, approved product lists and version history in a format your assessor can sample.
- Walk your team through where each artifact lives, who owns it and how it is reviewed.
- Provide a mapping of each 12.2.1 element to its evidence location so your QSA can test it without guesswork.
How we support
- Offer ongoing support as a retainer to update approved lists and policy wording as technologies change.
- Re-check approvals and acceptable uses during periodic reviews so evidence stays current between assessments.
- Confirm with your QSA or assessor which evidence formats and sampling they will accept before final handover.
