What PCI DSS 9.3 asks for and where audits find gaps
Requirement 9.3 asks you to control physical access for personnel and visitors to areas where cardholder data is stored, processed or transmitted, and to keep evidence that the controls work. If you are a QSA preparing a Report on Compliance or an organization completing an SAQ, the question an assessor will put to you is simple: can you show who was allowed into the sensitive areas, when that access ended, and who signed off on visitors? The risk behind the requirement is direct. A person without a legitimate reason to be in a data center, back office or card-handling room can reach servers, paper records or card-present devices, and no network control helps once they are inside. The requirement has five sub-requirements. Requirement 9.3.1 covers the procedures for authorizing staff physical access and reviewing it. Requirement 9.3.1.1 requires access to sensitive areas to be revoked immediately on termination, with keys and access cards returned or disabled. Requirement 9.3.2 covers how visitors are authorized before they enter, 9.3.3 requires visitor badges or identification that is surrendered on leaving, and 9.3.4 requires a visitor log. In v4.0.1, the glossary in Appendix G defines visitor, so your visitor rules should use that definition, including who counts as a visitor and who does not, such as contractors who hold their own authorized badges.
Revocation timing and visitor logs are where audits usually find gaps. For revocation, assessors compare HR termination dates with badge deactivation timestamps from your access control system, and they look for former contractors, shared keys and cards that were never collected. Confirm that your offboarding ticket triggers physical access removal, not only system account removal, and that you can produce the timestamp. For the visitor log, check that every entry records the visitor's name and organization, the date and time, and the person who authorized access, and that logs are retained for at least three months unless local law restricts retention. Ask your facilities team to test the log against a sample of recent visits before the assessment starts.
Which people, areas and third parties 9.3 applies to
Requirement 9.3 applies wherever cardholder data is physically accessible, not only to the payment team. The cards below show which people, rooms and outside parties fall inside that boundary, and where scoping decisions change the work.
Sensitive areas inside the facility
A sensitive area is any room where cardholder data is stored, processed or reachable, such as a server room, a card-printing area, a back office holding paper receipts or a network closet with payment switches. Defining these rooms is the first scoping decision, and it determines which access rules, badge readers and visitor controls apply. Document each room on the floor plan and list the systems inside it. Confirm the boundary with your QSA or acquirer before you assume a room is out of scope, because a room that looks like office space may still hold a terminal or a backup drive.
Employees and contractors with badges
Personnel who enter sensitive areas need documented authorization, and the badge procedure should show who approved each grant and what access it gives. Contractors on fixed-term projects often hold badges longer than their work requires, so their access should expire with the contract. Review the badge list against the current staff roster and the active project list. Ask your QSA which evidence they will sample, typically the authorization record and the revocation record for leavers.
Visitors and escorted guests
Visitors include auditors, couriers, vendors on short visits and job candidates, and each category needs a defined path into the building. Requirement 9.3 expects visitors to be authorized, to be identifiable as visitors, and to surrender any badge when they leave. Decide in advance whether guests are escorted at all times in sensitive areas, and record how escorts are assigned. Keep the visitor log entries for the people actually admitted, since assessors compare the log against badge and door records.
Cleaning and maintenance vendors
Janitorial crews, HVAC technicians and facilities contractors often work after hours and may be the only people in a sensitive area without staff supervision. Their access is easy to overlook because it sits outside the payments team's own badge process. Agree in writing who badges them, who escorts them, and how their access is revoked when the service contract ends. Confirm whether the facilities provider's own staff are treated as visitors or as personnel, because the answer changes the evidence you must keep.
Shared buildings and colocation providers
When your cardholder data sits in a data center or shared office, the building owner, colocation operator and other tenants may control doors, cameras and visitor logs. Scope then depends on who holds the physical access keys and who can issue badges to your space. Request the colocation provider's physical security attestation and its visitor procedures, and confirm which of them your QSA will accept as evidence for your part of the building. If the provider holds access that your own team cannot audit, record that dependency in your scope documentation.
Access grants that must end on termination
Requirement 9.3.1.1 expects physical access to sensitive areas to be revoked immediately when someone leaves, with keys and cards returned or disabled. Physical revocation often lags behind directory deprovisioning, so a former employee can still open a door after losing system access. Connect the HR leaver process to badge deactivation and key recovery, and test it with real leaver records. Identity tooling can help with the directory side. For example, authentik's SCIM provider deprovisions users from target applications, but it does not control door hardware, so badge systems need their own revocation step.
How an assessor tests 9.3 for staff, sensitive areas and visitors
For personnel access, an assessor first reads the written procedures that govern how staff receive, change and lose physical access to areas that hold cardholder data. They then compare those procedures with real records. A common approach is to take a list of personnel who left during the assessment period from HR, then trace each name to the badge system, key registers and any access list for sensitive areas to confirm access was revoked promptly. The assessor also samples current badge holders and checks each one against an active employment or contractor record.
- Procedure review: the assessor confirms the procedure covers issuing, changing and revoking badges, keys and access cards for staff and contractors.
- Termination sample: names drawn from HR leaver reports are traced to badge and key system records, with timestamps compared to the termination date.
- Active holder sample: current badge holders are matched to active identity records to catch orphaned access.
- Evidence requested: badge system exports, key logs, HR termination tickets, and any deprovisioning records showing when access was disabled.
- Common findings: terminated staff still holding badges, access removed days after departure, or revocation performed by hand with no record.
Confirm with your HR and facilities teams how a leaver's physical access is linked to their identity record, and ask who can disable a badge outside business hours.
Sensitive areas such as data centers, server rooms and card production rooms need a tighter review than general office space. An assessor typically asks who holds access to each sensitive area, why each person needs it, and when the list was last reviewed and approved. The sample usually covers every sensitive area in scope, with the access list compared against the business need documented by its owner. Assessors look for evidence that someone independent of the holder approved the access and that unneeded entries were removed during the review.
- Area inventory: the assessor confirms which rooms and cabinets count as sensitive and that each one has a current access list.
- Review record: dated sign-offs by an accountable owner show the list was checked and changes were made.
- Need-to-access check: a sample of holders is traced to a documented role or duty that requires entry.
- Evidence requested: access lists per area, review minutes or approvals, and change tickets for grants and removals.
- Common findings: access lists never reviewed, contractor badges with no end date, or reviews signed by the same person who granted the access.
Confirm how often your reviews run and whether the reviewer is independent of the person who requested the access.
Visitor testing covers two linked points: whether visitors are authorized, escorted and badged, and whether the visitor log holds the required entries for at least three months. An assessor usually selects visit days or visitor records across the retention window and checks each entry against badge issuance, escort evidence and the authorizing employee. Log retention is tested by confirming that older entries still exist and are not overwritten. The assessor also checks that visitor badges are surrendered at exit, using return records or badge deactivation timestamps.
- Log field check: each sampled entry is checked for the visitor's name, organization, date and time, and the person who authorized access.
- Retention check: the assessor confirms entries from the start of the retention window are still available.
- Badge surrender: returned badges are matched to exit entries or deactivation records.
- Evidence requested: the visitor log in its native form, badge issuance records, escort assignments and visitor badge inventories.
- Common findings: logs missing the authorizer, paper logs that were discarded early, or visitor badges never reconciled at exit.
Confirm that the log format captures every required field and that your retention period meets the three-month minimum, unless local law requires otherwise.
How to implement 9.3 in order, with the output of each step
This sequence moves from written procedures to a working badge, termination and visitor process, then to retained logs and a first review. Each step leaves a document or record that an assessor can test against Requirement 9.3.
Document badge and personnel access procedures
The security or facilities lead writes the procedures that govern how staff and contractors receive, use, and surrender physical access badges and keys, including who approves access and how sensitive areas are identified. Confirm the document with HR, facilities and the people who issue badges so the process matches daily practice. The output is an approved, dated procedure with named owners, which the assessor will read first when testing 9.3.1.
Map sensitive areas and access rights
Facilities and the CDE owner list every room, rack, cage or office where cardholder data or the systems that hold it are physically reachable, then assign each area a named set of approvers. Record which badge groups or keys open each area, so the access list can be compared with the approved roles later. The output is a sensitive-area register tied to badge groups, which becomes the reference for the access review in step six.
Link HR termination to physical access removal
Work with HR and the badge system owner to define a termination trigger that removes physical access to sensitive areas immediately, covering badges, keys, and remote badge readers. Test the path with a sample leaver, confirming that the badge is disabled and any returned keys are logged. The output is a documented termination workflow and a test record showing the removal time, which an assessor will compare against the employee's exit date under 9.3.1.1.
Set up visitor sign-in and escort rules
Define how visitors are authorized, identified and badged, how their badges are surrendered at exit, and who must escort them inside sensitive areas. Train reception and the staff who host visitors on these rules, and confirm the sign-in form captures the visitor's name, organization, date, time and the authorizing person. The output is a visitor procedure, a sign-in form or electronic log template, and a training record for staff who receive visitors.
Configure visitor log retention
Set the visitor log to hold entries for at least three months, unless a legal restriction applies, and restrict who can read or change the records. Where logs are electronic, confirm that the system keeps entries in a form that cannot be silently edited and that retention is enforced rather than manually managed. The output is a retention setting or storage rule, a written statement of the retention period and any legal exception, and a sample export showing entries older than the start of the retention window still present.
Run a first access review
Compare the current list of people with physical access to each sensitive area against the approved roles in the sensitive-area register, and remove or justify every mismatch. Record the reviewer, the date, the findings and the corrective action taken. The output is a signed review record and a list of closed exceptions, which gives the compliance lead evidence that the process works from the first cycle onward.
How automated deprovisioning supports same-day badge revocation
Requirement 9.3.1.1 ties physical access to sensitive areas to termination, so the revocation step is only as fast as the identity lifecycle behind it. The practical question for a CISO or platform lead is whether a termination recorded in HR or the directory automatically reaches the systems that open doors, or whether someone must remember to act on a ticket. Manual steps are where badges stay active for weeks. Start by mapping which system is the authoritative source for employment status, which systems grant physical access, and who owns each handoff. An identity provider can carry those account changes downstream. The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. That behavior helps with logical systems such as the access control administration console, badge management software or visitor management tools that accept SCIM or a comparable provisioning interface. Whether a given badge or access control product accepts provisioning from an identity provider, and whether it disables a card as well as the user record, must be confirmed with that vendor. Ask for the exact API or connector, the disable action it performs, and whether it is logged. Automation does not catch access that was granted correctly and then accumulated. Recurring access certification fills that gap. The *access certification campaigns* in midPoint let designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. Apply the same discipline to physical groups: reviewers confirm that each person still needs the sensitive-area badge profile, and the outcome is recorded as evidence. Confirm the review frequency with your QSA and keep the reviewer decisions, not just the campaign configuration, because the assessor will ask for proof that the review happened.
Evidence that passes 9.3 and how to keep it current
An assessor testing Requirement 9.3 looks for records that show who was let in, who was escorted, when access ended and who checked it. Each card below is one artifact, and each depends on the others, so gaps in one usually surface in another. The guidance focuses on keeping every artifact current between assessments, not just assembling them for the audit.
Termination records matched to badge disablement
Assessors compare the HR termination date and time with the moment physical access to sensitive areas was revoked. Keep the termination ticket, the badge system deactivation log and the key or card return record together, and check that the timestamps agree. Between audits, run a recurring comparison of terminated staff against active badge holders and record any mismatch with its root cause. Ask your badge vendor whether deactivation events are exportable with timestamps.
Visitor log with required fields
The visitor log must record the visitor's name, organization, date and time, and the person who authorized the access. Assessors sample entries and check that every field is filled in, not just the name. Keep the log in one controlled format, whether paper or electronic, and retain it for at least three months unless local law restricts retention. Review a sample of entries each month to catch blank authorizer fields before an assessor does.
Visitor badge surrender records
Badges issued to visitors should be returned when the visit ends, and the return should be recorded against the visitor log entry. Keep a daily reconciliation of badges issued against badges returned, with a documented follow-up for any badge not accounted for. Assessors often ask what happened to unreturned badges, so the follow-up record matters as much as the return record. Confirm with your facilities team how lost badges are deactivated.
Escort and badge procedures
The written procedure should state which visitors must be escorted, who may escort them and how a visitor badge is distinguished from a staff badge. Assessors test whether staff follow the procedure, so keep training acknowledgements and spot-check records. Review the procedure whenever the facility layout, badge design or sensitive areas change, and record the review date and approver. Ask your team to confirm the procedure matches what staff actually do at the door.
Periodic access reviews
A periodic review confirms that everyone with physical access to sensitive areas still needs it. Reviewers compare the current badge holder list against role and business need, and they record which access was kept, changed or revoked. Automated campaigns in identity tools such as midPoint can route these decisions to named reviewers within a set timeframe, which leaves a dated decision trail. Set the review cadence in your policy and keep each completed review as a signed record.
Deprovisioning from connected identity systems
Physical badge revocation often has to be matched with the identity directory that feeds it. If your directory deprovisions a user, the badge system and other connected applications should follow. Connectors such as the authentik SCIM provider push deletions and changes to target applications and run a full sync every hour, which narrows the window between termination and removal. Keep sync logs and the list of systems that receive deprovisioning events, and check them against your physical access list each quarter.
What meeting 9.3 costs in money and effort
This table lists each cost component of meeting Requirement 9.3, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price figures are supplied for these components and the real totals depend on your sites, badge system and termination volume.
| Cost component | Who is paid or who carries the work | One-time or recurring | What drives it |
|---|---|---|---|
| Badge and visitor management licenses | Software vendor or open-source deployment partner | Licenses often recur; setup is one-time | Number of sites, badge holders and visitor volume; open-source options can reduce license spend |
| Engineering time for integrations | Internal platform team or implementation partner | One-time, with ongoing maintenance | Number of systems that must receive access changes, such as directory and access control platforms |
| HR and termination process time | HR, facilities and line managers | Recurring | Termination volume and how many handoffs exist between HR, IT and facilities |
| Facilities and badge administration | Facilities or security staff | Recurring | Number of sites, badge age and the frequency of lost or replaced cards |
| Visitor log and escort handling | Front desk, reception and host employees | Recurring | Visitor volume, escort ratios and whether the log is electronic or paper |
| Evidence upkeep | Compliance lead and system owners | Recurring | Frequency of access reviews, log retention and how well records are kept as they are created |
| External review and gap checks | Independent consultant or implementation partner (independent of the assessor) | Often one-time before assessment, then periodic | Scope size, prior findings and the maturity of existing procedures |
| QSA sampling time | Qualified Security Assessor, paid by your organization | Recurring at each validation cycle | Number of sites and samples the assessor selects; clean, ready evidence shortens the review |
| Quote items to request | Your procurement team | Ask for each item separately | Ask vendors and partners to state one-time setup, recurring licenses and support, and what is excluded |
Who owns 9.3: your team, a partner and the QSA
Your organization owns every physical access control under 9.3. Assessors test whether your staff actually follow the procedures, so the people who issue badges, escort visitors and keep the log must be accountable for doing so. Ownership cannot be transferred to a vendor, even when a vendor supplies the tooling.
- Access procedures: Written procedures for personnel access to sensitive areas, approved by a named owner and reviewed on a schedule you set.
- Badge issuance and revocation: Your HR and facilities teams approve badges, and someone accountable confirms immediate revocation on termination, including return or disabling of keys and cards.
- Visitor handling: Front-desk and escort staff authorize visitors, issue badges and collect them on departure.
- Visitor log custody: Your team decides where the log lives, who can read it, and how long it is kept beyond the minimum retention period.
- Evidence on request: Staff who can explain the process and produce records for a sample of dates, people and visitors.
Before engaging anyone, confirm which named role signs off each procedure and who answers the assessor's questions about it.
An implementation partner such as DeployOpen can help prepare the systems and records that support 9.3, but it does not decide whether your controls are sufficient or whether they pass. Partners are most useful where access decisions must flow through software, such as identity provisioning, access reviews and log storage in self-hosted platforms.
- Identity lifecycle integration: Connecting a self-hosted identity provider to physical access or facility systems so that a termination in the directory triggers revocation. For example, an identity platform's SCIM provider can deprovision users from a target application when they lose access, but whether a door system accepts that signal must be confirmed with the door vendor.
- Access certification support: Configuring review campaigns so designated reviewers confirm or revoke access items on a set timeframe.
- Log infrastructure: Building a central, access-controlled store for visitor log entries with the fields the requirement names.
- Evidence packaging: Exporting dated records, configuration screenshots and procedure versions in a form your assessor can sample.
- Documentation: Writing runbooks that match the procedures your team has approved.
Ask the partner for a written scope that names each system touched, the evidence it will produce, and who signs off that the work is complete.
A Qualified Security Assessor (QSA) tests 9.3 as part of a Report on Compliance and documents the result. Only the QSA can issue that report. Independence means the assessor may not design or operate the controls it tests, so the partner that built the integrations cannot also write the findings on them.
- Sampling: The QSA selects people, visitors and dates, then asks for the badge records, revocation timestamps and visitor log entries that cover them.
- Interviews and observation: The QSA walks the facility, watches the visitor process and asks staff to explain their steps.
- Testing revocation: The QSA compares termination records with access system states to check that revocation happened immediately.
- Log review: The QSA checks that entries include the visitor's name and organization, date and time, and the authorizing person, and that retention is at least the minimum period.
- Reporting: The QSA records findings in the ROC or the relevant self-assessment questionnaire and the Attestation of Compliance follows.
Agree the assessor's scope and sampling approach early, and confirm with the QSA which evidence it expects before you build any new system.
Organizations commonly outsource the technical parts of 9.3 and keep the accountable decisions in house. Costs for outsourced work are usually one-time for setup and recurring for support, changes and periodic evidence preparation, and the scope agreed in writing defines both.
- Usually outsourced: Identity integration work, configuration of review campaigns, log storage design and the evidence export scripts.
- Usually kept in house: Approval of visitor and badge policy, termination decisions, escort duties and the custody of the visitor log.
- Cost drivers: The number of facilities and access systems, the number of integrations, and how often procedures change.
- Quote questions: Which systems are in scope, which deliverables are one-time, which are recurring, and who maintains the integrations after handover.
- Shared boundaries: Vendors of physical access hardware may control parts of the system, so confirm their responsibilities in writing.
Do not treat outsourcing as a transfer of responsibility. Your organization still answers for every 9.3 control to the assessor.
Independence matters because the QSA's report is only useful if the assessor was not responsible for the controls it judges. A consultant that designs, configures and operates the controls can help you prepare, but the same firm should not then validate those controls. Confirm this separation before you sign any engagement.
- Clear line: Partners prepare systems, integrations and evidence. The QSA tests them and issues the report.
- Avoid self-review: Where one firm both builds a control and assesses it, the assessor may need to decline the work or document the conflict.
- Ask the QSA: Which pre-assessment help it will accept, and how it handles prior involvement by the firm you hire.
- Written boundaries: Put in the partner agreement that it will not issue attestations, certificates or compliance statements.
- Certificates are not validation: Any document claiming 9.3 compliance without an assessor's report or completed questionnaire has no standing with payment brands.
Before engaging a partner, ask the QSA to confirm in writing that the proposed division of work does not create a conflict.
Common 9.3 gaps and how to close them
Most 9.3 findings come from process gaps between HR, facilities and system owners rather than from missing locks or badges. The cards below cover the five gaps assessors most often raise, each with a practical fix you can verify before the assessment starts.
Slow termination revocation
Requirement 9.3.1.1 expects physical access to sensitive areas to be revoked immediately on termination. The gap usually appears when HR closes the employee record days after the last working day, while facilities deactivates the badge only when someone remembers. Tie badge deactivation to the same termination ticket that disables directory accounts, and make the facilities step a named task with a timestamp. Check the gap by comparing termination dates in HR records against badge system deactivation times for a sample of leavers.
Keys and cards not returned
Physical credentials left with a leaver, such as spare keys, shared door fobs or unused access cards, are a common assessor finding because they bypass the badge system entirely. Keep a register of issued physical keys and cards for each sensitive area, and require a signed return or documented disablement before final pay or contractor sign-off. Ask for the register and a sample of recent return records during your own readiness review.
Visitor logs missing fields or retention
The visitor log must record the visitor's name and organization, the date and time, and the person who authorized access. Paper logs often omit the organization or the authorizer, and electronic logs are sometimes purged on a schedule nobody reviewed. Use a form with mandatory fields, and set retention to at least three months unless local law limits it. Confirm the retention setting in the actual system rather than trusting the policy document.
Visitors unescorted in sensitive areas
Badged visitors who wander into sensitive areas without an escort undermine the visitor controls in 9.3. Requirement 9.3.2 expects visitors to be authorized before access and escorted or otherwise supervised. Post escort rules at sensitive-area doors, configure badges so visitor credentials cannot open them, and require visitors to surrender badges at exit. Walk the route with a visitor during readiness testing and record what they could reach.
Unreviewed physical and logical access
Access granted for a project or a role often stays long after the need ends, and nobody reviews it because physical and system access sit in different owners' hands. Schedule periodic reviews of who holds badge access to sensitive areas, compare that list with current job roles and directory groups, and record the reviewer's decision. Open-source identity tools can generate the review population and track revocations, but the reviewer must still make and document each decision.
Questions buyers ask about 9.3 cost, time and effort
What does it cost to meet PCI DSS requirement 9.3?
No supplied source gives a price for meeting 9.3, and DeployOpen does not publish one. Cost comes from four components: internal staff time to write and run the badge, visitor and termination procedures, any badge or access system changes, the assessor's fee for testing the controls, and any outside help you choose to buy. Most of the spend is labor, not hardware. Ask any provider for a quote built from a written scope that lists the facilities, access systems and visitor processes in scope, the deliverables and the evidence each one produces. Ask which costs are one-time, such as procedure drafting and system configuration, and which recur, such as quarterly access reviews and log retention.
How long does it take to prepare for 9.3 visitor and badge controls?
No supplied source gives a duration for this work, so treat any timeline as something to confirm with your team, provider and assessor. Preparation time depends on how many facilities hold cardholder data, whether badge and visitor processes already exist, and whether termination revocation is tied to an HR system you can integrate. A site that already issues badges, escorts visitors and keeps a sign-in book needs mainly documentation and evidence work. A site that relies on shared keys or paper-only sign-in needs process change first. Ask for a schedule with milestones that match the evidence your assessor will request.
Can our team meet 9.3 without outside help?
Yes, in principle. Requirement 9.3 is procedural and most of its evidence is records your own staff can produce: written badge procedures, a current list of personnel with sensitive-area access, visitor logs and records of badge surrender. Outside help is useful when your team lacks time to write procedures, needs identity or access tooling configured, or wants a second review before the assessor arrives. Be clear about roles. Your organization owns the control. An implementation partner can prepare systems and evidence, but only an independent QSA issues the Report on Compliance or validates the controls. Consulting and assessment should stay with separate firms where possible.
What does 9.3 need from facilities and HR teams?
Requirement 9.3 depends on two non-security teams. Facilities controls physical entry points, badge issuance, escort rules, visitor sign-in and badge return. HR controls the trigger for removing access, because revocation on termination only works if HR tells the access owner the same day. Facilities should own the visitor log format and retention, and HR should own the termination workflow. Agree on these responsibilities in writing and name a contact in each team. Ask your assessor which records they will request from each team so both are ready before fieldwork starts.
How does a QSA check the visitor log under 9.3?
The QSA samples visitor log entries and compares them with other evidence. Expect them to confirm that each entry records the visitor's name and organization, the date and time, and the person who authorized access, and that the log is kept for at least three months unless local law restricts retention. They will also check that visitors were authorized and escorted, and that badges were surrendered. Samples usually come from several dates and sites. Keep the log complete and tamper-evident, and keep a short list of who authorized each visit so the assessor can trace a sample back to its approval.
Which 9.3 tasks are automated and which stay manual?
Revocation can be automated. Identity platforms that support SCIM provisioning can push deletions to connected applications, and directory services can centralize access groups. For example, an identity platform such as authentik's SCIM provider can deprovision users from a target application when they lose access. Physical access to doors and facilities is usually controlled by a separate badge system, so you must confirm whether your badge system can be driven from the same identity source. Visitor sign-in, escort supervision and badge return normally remain manual unless you run a visitor management tool. Confirm each integration with your vendor before you rely on it.
Does PCI DSS certification or a certificate prove 9.3 is met?
No. Validation is documented on PCI SSC templates, either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance. The PCI SSC states that certificates are not recognized as validation. Your acquirer or payment brand decides which validation applies to you. Ask your assessor to confirm which template and how 9.3 will be tested before you commit budget, and check the current PCI DSS version in the PCI SSC standards library, since v4.0.1 is the only active version as of the sources supplied.
How DeployOpen prepares 9.3 systems and evidence
DeployOpen works on requirement 9.3 by setting up the identity, badge and visitor records that show who was authorized to enter, when access ended and who escorted each visitor. The organization keeps ownership of its controls and decisions, while we prepare the systems and evidence that a QSA or the organization's own assessor can review.
How we scope
- We agree a written scope listing the facilities, sensitive areas and identity sources covered by 9.3 before work starts.
- We confirm with the organization which teams own badge issuance, termination notices and visitor logging.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.
How we build
- We configure directory and identity tooling so that a leaver's access to sensitive areas can be traced and removed promptly.
- We design a visitor log template capturing name, organization, date, time and authorizing person for the retention period.
- We test revocation and log retention with sample records so the organization sees the evidence before an assessment.
How we hand over
- We document the 9.3 procedures, owners and evidence locations in a handover pack the organization keeps.
- We provide sample evidence extracts that show a termination, a revocation and a completed visitor log entry.
- We confirm with the organization's QSA or assessor which evidence formats they will accept before final handover.
How we support
- Ongoing support, upgrades and periodic checks of 9.3 records are available as a retainer, agreed in writing.
- We review access certification results and visitor log completeness on the schedule the organization sets.
- Any validation decision, report or attestation remains with the organization and its independent assessor.
