Does PCI DSS apply to an MSP that never touches card data?
Yes. PCI DSS applies to service providers that can affect the security of account data even when they never store, process or transmit it, such as a managed service provider with remote or privileged access to a customer's cardholder data environment (CDE) (PCI SSC FAQ 1579). The provider's own assessment scope covers all people, processes and technology it uses to deliver that service (PCI SSC FAQ 1580). The question to answer first is therefore not whether card data passes through the MSP, but what the MSP can reach, how it gets there and who administers those paths. A jump host, a remote support tool, a monitoring agent with credentials to CDE systems or a help desk that can reset accounts in the CDE each brings the MSP into scope, even if no PAN ever appears in its own systems.
Ownership of each control follows the environment. The MSP is responsible for the controls on its own environment, including its administrator workstations, ticketing and remote access tooling, identity systems and staff. The customer remains responsible for the CDE itself, but the MSP may meet some requirements on the customer's behalf, and those must be documented as such. Under FAQ 1578, a provider offering a limited service must still meet every requirement applicable to that service and its supporting systems, so a narrow scope does not remove the obligation. Ask the MSP to list every path into the customer's CDE, every account that uses it and the owner of each control on that path before anyone argues about scope.
Access is the practical test. Requirement 8.2.7 requires third-party remote access accounts to be enabled only for the time needed, disabled when not in use and monitored for unexpected activity. Requirement 8.4.3 requires multi-factor authentication for remote network access from outside the entity's network that could affect the CDE, including vendors. Confirm with the customer and your QSA how each vendor path is authenticated, how sessions are time-limited and who reviews the logs. The matching evidence is an access register per customer, MFA configuration exports, and recorded approvals for each access window. Whether an MSP's assessment is a ROC or an SAQ D for Service Providers depends on the service and the assessor's view, so confirm that with the assessor rather than assuming it.
How the MSP's own assessment scope is set
An MSP's own PCI DSS scope is set by the systems and people it uses to reach customer environments, not by whether it stores card data. FAQ 1578 makes clear that even a narrow service carries the full set of requirements that apply to that service and its supporting systems.
Ticketing and remote support tools
Ticketing, remote session and screen-sharing tools hold customer credentials, session records and sometimes screenshots that show card data on a customer's screen. If these systems can reach or influence a customer's CDE, they belong in the MSP's scope. Check which tool stores connection details, who can export them, and whether the vendor's AOC covers the service you actually use.
Jump hosts and bastion servers
Jump hosts are the most common path from the MSP's network into a customer's CDE, so they are a primary scope item. Each host needs hardening, logging of every session, and restricted outbound paths. Confirm that no customer-specific jump host is shared across unrelated clients without a documented separation control.
Administrator workstations
Engineers who administer customer systems typically work from laptops or virtual desktops that also handle email and browsing. Those endpoints can hold saved sessions, keys and tokens that reach the customer CDE. Document which workstations are used for customer work, how they are built and patched, and how malware protection and local admin rights are managed.
Identity and directory systems
The MSP's identity provider, directory and privileged access tooling decide who can reach customer environments and with what rights. A compromise here reaches every client at once. Map which directories issue credentials for customer access, who administers them, and how MFA and account lifecycle controls are enforced for those accounts.
Monitoring and logging platforms
Security monitoring, log collection and alerting systems usually receive records from customer-facing activity, so they can contain sensitive data and must be protected. They also show whether MSP access is being watched. Confirm where logs from customer engagements are stored, who can read or delete them, and how long they are retained.
Staff who hold customer access
People are in scope too. Every engineer, help desk agent and contractor with access to a customer CDE is part of the assessed population, so the MSP must be able to list them and show how their access is granted, reviewed and removed. Ask whether access lists are reconciled against HR records and whether background screening and awareness training are documented for each role.
What changes by access model
A VPN tunnel that lets vendor engineers reach systems inside the customer's network is remote network access from outside the customer's network. Requirement 8.4.3 applies to it, so multi-factor authentication must be in place for every such session, including sessions opened by the MSP's own staff. Requirement 8.2.7 applies to the vendor accounts that sit behind the tunnel, so those accounts should be enabled only for approved work windows and disabled when idle.
- MFA on every session: Each remote session needs MFA, and the MSP should document which factors its engineers use and how the customer can verify them.
- Time-bound vendor accounts: Account enablement should follow approved change or support windows, with monitoring for unexpected logins.
- Logging of session start and end: VPN concentrator logs should record who connected, when and from where, and they should flow to a system the MSP cannot quietly edit.
- Customer-retained control: The customer usually keeps the VPN gateway, the firewall rules that admit the tunnel and the approval step that enables vendor accounts.
Before signing, ask the customer which VPN gateway logs it can see and whether its own team can revoke vendor access without the MSP's help.
A bastion host, sometimes called a jump server, is a hardened system through which administrators reach CDE systems. Non-console administrative access into the CDE must use MFA under Requirement 8.4.1, and the bastion is usually the point where that control is enforced. The bastion also concentrates session recording, so it becomes one of the most important evidence sources an assessor will sample.
- MFA at the bastion and at the target: Confirm whether the bastion enforces MFA for every administrator and whether each target system adds its own check where the design requires it.
- Individual accounts only: Shared administrator logins are a known audit failure. Requirement 8.2 and PCI SSC FAQ 1080 explain why credentials must be unique to each person.
- Session recording and command logs: Record privileged sessions and retain them under the customer's log retention rules, protected from alteration by the MSP's administrators.
- Customer-retained control: The customer typically owns the bastion's authorization policy, the list of who may hold a privileged role and the review of those grants.
Ask the MSP to show a sample session recording and the matching bastion authentication log, then confirm where those records are stored and who can delete them.
A managed security monitoring provider that collects logs from the CDE is not usually an administrator, but it still touches cardholder data environment evidence and often has its own remote access into the collection pipeline. Requirement 10 covers the logs themselves: audit trails must be protected, reviewed and retained, and time must be synchronized. The provider's access to the log platform also falls under the access and MFA duties for third-party remote access.
- Read-only scope: Limit the provider to the log sources and dashboards it needs, and document any write or response capability separately.
- MFA and account duties for the portal: Any remote console or API token used to reach the platform should be covered by MFA and by the disablement rules for inactive vendor accounts.
- Log integrity: Logs forwarded to the provider should remain available in the customer's own store so that a provider change does not erase audit history.
- Customer-retained control: The customer usually decides which systems send logs, what retention applies and who receives alerts about control failures.
Confirm in writing whether the provider can change log routing or silence alerts, because either action would alter evidence the customer must keep.
Help-desk staff who reset passwords, unlock accounts or open remote sessions on in-scope systems can change the security state of the CDE from a service desk tool. Their access is often the easiest to overlook because it looks routine. Requirement 7 governs least-privilege access by business need, and Requirement 8 governs how the help desk identifies itself and how its accounts are controlled.
- Least-privilege roles: Help-desk roles should allow only the actions the support queue requires, not general administrator rights.
- Identity verification for resets: Procedures for resetting an in-scope user's credentials should verify the requester and be logged.
- Remote-control tooling: Any remote assistance tool that reaches CDE endpoints needs MFA for its operators and a session log.
- Customer-retained control: The customer usually approves which help-desk roles can reach in-scope systems and reviews those grants on a schedule it sets.
Ask the MSP for its help-desk role list and the last access review of those roles, and confirm whether the customer's identity system or the MSP's tooling is the record of truth.
Vendor remote access, MFA and account rules
An MSP's remote access into a customer's CDE is one of the first things an assessor and the customer will examine. Requirement 8.2.7 asks that third-party remote access accounts be enabled only for the time needed, disabled when not in use, and monitored for unexpected activity. For an MSP, this means each engineer's or vendor account used for a customer should have a documented business reason, an activation window tied to a ticket or change, and automatic or routine disablement when the work ends. Confirm the exact wording and testing procedures for 8.2.7 in your current SAQ D or ROC template, and check whether your customer's assessor expects the activation records to be kept as evidence.
Requirement 8.4 covers multi-factor authentication in three parts. Requirement 8.4.1 applies MFA to all non-console administrative access into the CDE, Requirement 8.4.2 applies MFA to all access into the CDE, and Requirement 8.4.3 applies MFA to remote network access from outside the entity's network that could affect the CDE, including access by third parties and vendors. For an MSP, the 8.4.3 requirement is the one most likely to apply to your own staff connecting from home or from a provider's office. Map every path into each customer environment (VPN, jump host, bastion, privileged access tool, vendor portal) and confirm that MFA is enforced at each one, not only at the front door.
Two PCI SSC FAQs narrow the practical questions. FAQ 1596 addresses whether phishing-resistant authentication satisfies 8.4.1 and 8.4.3, which is worth reviewing before you select an authenticator for administrators. FAQ 1595 addresses synced passkeys under 8.4.2, so confirm how your platform stores and recovers passkeys before relying on them. Also check FAQ 1066 on inactive user accounts and FAQ 1080 on shared authentication credentials, because shared jump-host logins are a common finding for MSPs. Document the account lifecycle, the MFA method for each access path, and the monitoring records, and have a qualified assessor confirm the interpretation for your environment.
Written acknowledgments and status evidence for customers
This sequence turns a managed service provider's responsibilities into written commitments and an evidence set that each customer can check before and after onboarding. It gives customers what they need to meet their own Requirement 12.8 duties, and it leaves the provider able to show proof when asked.
Confirm which customer requirements the provider touches
Start from the list of customer environments and services the provider accesses, then mark each PCI DSS requirement that the provider performs, supports or could affect on that customer's behalf. Assign the work to the service owner and the compliance lead together, because the service owner knows the tasks and the compliance lead knows the requirement wording. The step is done when every service has a list of requirements tied to it, with no service left unmapped. Confirm the final list against your own assessment scope, since FAQ 1580 treats all people, processes and technology used to deliver the service as in scope.
Draft the written acknowledgment of responsibility
Requirement 12.9.1 expects the provider to acknowledge to each customer, in writing, that it is responsible for the security of the account data it stores, processes, transmits or could affect. Legal and compliance staff draft the text, and it should name the services covered and reference the responsibility matrix rather than repeat it. Review the wording with your contracts team so it matches the master agreement. The output is a signed acknowledgment template with a version date and a named signatory, ready to attach to each customer contract.
Build the responsibility matrix for each customer
For each customer, record which requirements the provider meets, which the customer meets and which are shared, with the evidence location for each entry. This matrix supports Requirement 12.8.5, which asks customers to know which requirements are managed by the provider, and it is the document customers will request first. The compliance lead owns it and the technical owners of each control confirm their rows. It is complete when every row names an owner, a control and an evidence source, and when the customer has received a copy.
Assemble the current AOC and evidence pack
Prepare the provider's current Attestation of Compliance, the scope statement it covers, and a short index of supporting evidence such as policy references, access review records and penetration test summaries. Under FAQ 1576, a provider should be able to give customers evidence of the requirements it meets for them. Confirm the AOC is current and that its scope includes the services sold to that customer. The output is a versioned evidence pack, stored under restricted access and released through a documented request process.
Set up the status request process
Define how a customer asks for compliance status and responsibility information, who approves the release, and how long a response is kept on file. Requirement 12.9.2 expects the provider to supply this on request, which supports the customer's own checks under Requirements 12.8.4 and 12.8.5. Assign a named contact and a single intake channel, and log each request with the material sent. The step is done when a test request runs end to end and the log shows the response.
Test the evidence against the customer's questions
Walk through the most likely customer questions, such as how remote vendor access is approved, how MFA is enforced and who reviews access, and check that each answer points to evidence in the pack. Gaps found here are logged with an owner and a fix date. The output is a tested evidence pack and a list of open gaps that the compliance lead tracks until closed. Keep in mind that an assessor will check the evidence itself, not the answer alone.
Handle missing evidence and document the outcome
If the provider cannot show evidence that a requirement is met for a customer, FAQ 1312 says that requirement is not in place for that customer, even if the provider believes it is operating the control. In that case, the compliance lead informs the customer in writing, records the gap, and agrees a remediation path or a customer-side compensating step with the customer. Record the outcome in the matrix and the acknowledgment file. The step closes when the customer has a written response and the gap is either resolved or accepted by both sides.
Validation route: SAQ D for service providers or a ROC
This table compares the SAQ D for service providers with a Report on Compliance completed by a QSA, showing who completes each, when a payment brand typically asks for a ROC and when a self-assessment fits. Read it to match the validation route to your contracts and volume, then confirm the level with each payment brand, since a validated MSP still has to show evidence to every customer.
| Factor | SAQ D for service providers | ROC completed by a QSA |
|---|---|---|
| Who completes it | The service provider's own team, using the official PCI SSC questionnaire and an Attestation of Compliance | A Qualified Security Assessor who tests controls and writes the Report on Compliance and Attestation of Compliance |
| When it fits | Service providers that a payment brand or acquirer allows to self-validate for their service level | Service providers that a payment brand's validation level requires to be assessed by a QSA (confirm the level with the brand) |
| Depth of testing | Customer-facing answers supported by the entity's own evidence, reviewed by its own staff | Independent testing of each in-scope requirement, with samples and interviews observed by the assessor |
| Customer evidence | The AOC supports customer reviews, but each customer may still request responsibility and control evidence under 12.9.2 | The ROC and AOC support customer reviews, but each customer may still request responsibility and control evidence under 12.9.2 |
| What to confirm | Your payment brand's current validation level for your service, and whether your customers accept an SAQ D | The QSA's independence, the Visa validation page for thresholds, and the scope the QSA will test |
Who owns which part of the MSP's program
The managed service provider remains accountable for every PCI DSS requirement that applies to its services and supporting systems, even when it has no stored card data. Its own team decides the service scope, owns the policies and risk decisions, and signs the written acknowledgments customers rely on. Because PCI DSS scope for a service provider covers all people, processes and technology used to deliver the service, the internal team must also maintain the inventory of those assets.
- Service scope and responsibility decisions: Define which customer CDEs the MSP touches, which requirements it meets for each customer, and which remain the customer's job.
- Access governance: Own the approval process for vendor accounts, the review cadence for third-party remote access, and the decision to disable accounts when work ends.
- Customer acknowledgments: Issue written acknowledgments of responsibility for account data security to each customer, and keep them current when services change.
- Operational evidence: Run the daily and periodic tasks, such as access reviews, log reviews and incident handling, and keep the records assessors will sample.
- Assessment preparation: Maintain the service provider's own assessment scope and supply the compliance status and responsibility information customers request.
Before relying on this tab, confirm with your customers which of these duties they expect you to hold in writing and which records they will ask to see on request.
An implementation partner such as DeployOpen can plan, configure and document the technical systems that the MSP uses to meet its obligations. Its work sits inside the provider's environment, on the MSP's infrastructure or the customer's, and follows a written scope agreed before work begins. DeployOpen prepares systems, controls and evidence for assessment. It does not issue reports, attestations or certificates, and it does not decide what the MSP's own compliance status is.
- MFA and access configuration: Set up multi-factor authentication for remote and administrative access paths that reach customer CDEs, including vendor access, in line with Requirement 8.4.
- Privileged access management: Configure session brokering, time-limited vendor accounts and automatic disabling of unused accounts for Requirement 8.2.7 workflows.
- Logging and evidence collection: Centralize audit logs, protect them from alteration, and build reports that show access events and reviews.
- Documentation and hardening: Produce configuration baselines, architecture diagrams and runbooks that describe how each control is implemented.
- Testing support: Run security testing that feeds the MSP's own vulnerability and penetration testing program, and document the findings and fixes.
When reviewing a proposal, ask the partner to list each deliverable against the requirements it supports and to state clearly what it will not do, including any claim to validate or certify the MSP.
A Qualified Security Assessor, or another assessor the payment brands recognize for the relevant assessment type, independently tests the MSP's controls and produces the official documentation. The assessor samples evidence, interviews staff, observes systems and records the results in a Report on Compliance, or confirms eligibility for a Self-Assessment Questionnaire with an Attestation of Compliance. Certificates are not recognized as validation, so the assessor's signed AOC or ROC is the document customers and payment brands will look for.
- Independent testing: The assessor tests the controls itself and does not accept the MSP's or the implementation partner's conclusions at face value.
- Scope confirmation: The assessor confirms which people, processes and technology fall inside the MSP's assessment and which services the customer's assessment depends on.
- Report issuance: Only the assessor issues the ROC or AOC, and the report states its own findings.
- Clear separation: An assessor cannot design or implement the controls it is evaluating for the same client without conflicting with its independence obligations, so ask how the firm handles that boundary.
- Payment brand rules: Confirm with the relevant payment brands which validation type and timing apply to the MSP's service provider status.
Before engaging an assessor, confirm its qualifications with the PCI SSC and ask for its written plan of the testing it will perform.
What drives the cost and effort for an MSP
An MSP's PCI DSS effort depends less on its own headcount than on how many customer environments it reaches, how those environments are accessed and how much evidence its customers ask for. The cards below cover the factors that move cost up or down, and what to put in a written, scoped quote from each party.
Number of customer environments
Each customer cardholder data environment the MSP can reach is a separate scope question, with its own responsibility split, its own evidence and its own set of customer requests. Count the environments by customer, by platform and by shared jump host, not by contract. Ask any assessor and any tooling vendor to price the work against that count, and confirm whether the quote covers new customers added during the year.
Privileged account count
The number of administrators, service accounts and vendor accounts that can act inside a customer environment drives the effort for access reviews, MFA enforcement and account disabling. Each shared or standing privileged account also adds a control that must be explained to an assessor. Ask for a current inventory of these accounts before requesting any quote, because the inventory itself is a deliverable most MSPs must produce first.
Tool sprawl
Every remote access tool, ticketing system, password vault, monitoring product and scripting platform used to reach customer systems becomes a component the MSP must document, configure and evidence. Consolidation usually lowers the recurring cost of keeping configurations current. Ask each party to state which tools are in the assessed scope and which the MSP will retire before the assessment starts.
Existing MFA enforcement
Where multi-factor authentication already covers every administrative and remote path into customer systems, the remaining work is mostly documentation and testing. Where it does not, the MSP must add identity controls, enrol accounts and handle exceptions for legacy tools, which is a larger one-time project. Confirm the current state with a written gap list, and ask each party to price the MFA rollout separately from the assessment.
Logging maturity
Assessors test whether access to customer systems is logged, protected, reviewed and retained, so gaps in logging for jump hosts and vendor sessions are costly to close late. Mature logging means central collection, time synchronization and documented review routines. Ask the implementation partner to confirm what it will build versus what the MSP already runs, and whether log storage and review are recurring services.
Annual evidence requests
How many evidence requests customers send each year, and how detailed they are, sets the recurring effort more than any single assessment. Customers may ask for the MSP's Attestation of Compliance, responsibility matrices, MFA records or access logs. Track the volume for a year before scoping, and ask each party to state in writing who answers these requests and whether that work is included in its fee.
Getting ready before the assessor arrives
This sequence turns an MSP's access to customer cardholder data environments into a documented, tested and explainable record that a QSA can sample. It ends with an assessment and an Attestation of Compliance that the MSP's customers can request and rely on.
Define the assessed service scope
Start by listing every service the MSP delivers to customers that touches, administers or could affect a customer CDE, including monitoring, patching, firewall management, help desk and backup. PCI DSS scope for a service provider covers all people, processes and technology involved in providing those services, so the list must include the MSP's own jump hosts, ticketing system, remote management tools and staff workstations. Scope is done when every service has a named owner and every supporting system is mapped to the service it supports. Confirm the scope with your QSA before work continues, since a limited service still carries the requirements that apply to it and its supporting systems.
Build the system and account inventory
Create an inventory of the MSP's systems, network segments, administrative accounts and vendor-facing accounts that reach customer environments. Record for each system what it connects to, who administers it and where its logs go. Include service and shared accounts, since shared authentication credentials and inactive accounts are common findings. The inventory is complete when a reviewer can trace any customer connection from the MSP's network back to a named system, a named owner and a logged account.
Review access model and account lifecycle
Document how staff and third parties receive, use and lose access to customer environments. Confirm that access follows business need, that privileged access is separated from daily use, and that accounts are removed or disabled promptly when people change roles or leave. Run a review of every account against HR and ticketing records, and disable any account that cannot be tied to an active need. The output is a signed access review with exceptions recorded and closed, which an assessor will sample against personnel changes.
Enforce MFA and control vendor remote access
Confirm that multi-factor authentication covers every administrative path into customer CDEs and every remote network path from outside the MSP's network, including access used by its own vendors. Requirement 8.4.3 applies to third parties and vendors connecting remotely, so vendor sessions need MFA, and Requirement 8.2.7 requires third-party remote access accounts to be enabled only for the time needed, disabled when idle and monitored for unexpected activity. Test each path, record the result and retain the configuration. Done means a test log showing that a password alone fails at every entry point.
Prepare the customer responsibility evidence pack
Assemble the evidence the MSP will give customers on request: its current AOC, a description of the services in scope, a responsibility matrix showing which requirements it meets for each customer and which remain with the customer, and records of its own testing and log review. Under Requirement 12.9.2, the MSP must be able to provide compliance status and responsibility information on request, so the pack must be retrievable without rebuilding it. Ask your QSA how the pack will be sampled, and keep a version history.
Issue written acknowledgments to customers
Draft a written acknowledgment that states the MSP's responsibility for the security of the account data it can affect for each customer. Requirement 12.9.1 requires this acknowledgment in writing, so the template must be reviewed by legal or contract owners and attached to each customer agreement or addendum. Track which customers have signed or accepted it, and store the signed copies with the contract record. The step is done when every active customer has a dated acknowledgment on file.
Complete the assessment and obtain the AOC
Run the assessment with an independent QSA or the applicable self-assessment questionnaire, depending on the entity's validation type as confirmed with its acquirer or the relevant payment brand. The QSA samples evidence, interviews staff and reviews configurations, then produces a Report on Compliance where required. The MSP receives an Attestation of Compliance once the assessment supports it. The MSP does not issue the AOC itself and should not treat a certificate as validation, because only the completed PCI SSC templates count. Confirm with the QSA which evidence gaps must close before the report is finalized.
Questions MSPs ask before a PCI DSS assessment
Do we need a ROC or an SAQ D as a managed service provider?
If you provide services that can affect the security of a customer's cardholder data environment, the validation template is generally the service provider SAQ D, but the decision belongs to the payment brands and your acquirer, not to you alone. Confirm your validation level and required template with them before planning. A Report on Compliance is completed by a Qualified Security Assessor and an SAQ D is self-completed, and each ends with an Attestation of Compliance. Your questionnaire or report must cover all people, processes and technology used to deliver the service, so the template choice follows the size and complexity of your operations as much as the card volume you handle. Ask your acquirer or the payment brand which validation level applies to you, and which template they accept.
Can we shrink our scope by not storing card data?
No. Not storing, processing or transmitting account data does not remove you from PCI DSS when you can affect a customer's cardholder data environment. The PCI SSC states that service providers with access to a customer's CDE, or that meet a requirement on a customer's behalf, fall under the standard even without handling card data. Your assessment scope covers all people, processes and technology involved in providing your services, including your jump hosts, ticketing tools, admin workstations and monitoring platforms. Where a service is limited, the SSC's guidance on SAQ eligibility still expects you to meet every requirement that applies to that service and its supporting systems. Reducing scope for an MSP usually means narrowing which of your systems can reach customer environments and how that access is controlled.
How do we prove our PCI DSS obligations to customers?
You prove them with a current Attestation of Compliance, a responsibility matrix and evidence that each requirement you own is operating. Requirement 12.9 applies only to service providers and asks you to acknowledge in writing to customers that you are responsible for the security of the account data you can affect, and to provide compliance status and responsibility information when a customer asks. Customers use that information to meet their own requirements 12.8.4 and 12.8.5. Certificates are not recognized as validation under PCI SSC guidance, so a logo or certificate will not satisfy a customer's review. Keep an evidence pack per requirement with dated configurations, access reviews, MFA logs, vulnerability scan results and penetration test reports that you can share under your confidentiality terms.
Can a partner do the PCI DSS work for us?
A partner can prepare systems, documentation and evidence, but it cannot validate your compliance. Your organization owns its controls and remains responsible for meeting each requirement it is accountable for. An implementation partner such as DeployOpen can plan, harden and document self-hosted platforms inside your own infrastructure, and it can run security testing that feeds your evidence. Only the Qualified Security Assessor or the validating entity issues the Report on Compliance or the SAQ attestation. Keep the preparation and assessment roles separate, because an assessor needs independence from the work it evaluates. Ask any provider to put the division of responsibilities in writing before work begins, and confirm with your QSA which of their outputs they will accept as evidence.
What does our team need to provide for a PCI DSS assessment?
Your team needs to supply the scope definition, system and data-flow documentation, the inventory of in-scope components and the evidence that your controls operate day to day. The assessor will check how you identify which systems can affect customer CDEs, how remote vendor access is enabled only for the time needed and disabled when idle, and how multi-factor authentication covers non-console administrative access, access into the CDE and remote network access by third parties. Requirement 8.2.7 expects third-party remote access to be monitored for unexpected activity, so prepare those logs. Assign a named owner for each requirement, keep current network diagrams and make sure staff can explain their own procedures. The exact list depends on your template and your assessor, so request their evidence request list early.
How do we handle a customer that asks for our AOC?
Share your current Attestation of Compliance under your confidentiality terms, and send the responsibility matrix that shows which requirements you meet, which the customer meets and which are shared. If a customer asks for detail beyond the AOC, respond with the compliance status and responsibility information that Requirement 12.9.2 anticipates, and do not send internal reports or raw evidence without an agreement in place. Check the AOC's date, the validation scope and the services it covers, because a customer may need a service you did not include. If you cannot show evidence for a requirement you meet on a customer's behalf, that requirement is not in place for the customer under PCI SSC guidance, so flag gaps early and agree on remediation timelines. Keep a log of requests so your responses stay consistent.
Checks before choosing a QSA or consultant
A managed service provider that touches customer cardholder data environments will be assessed by someone, and its customers will ask who that was. The checks below cover who can assess you, whether they are independent of the work you do, whether they understand service provider scope, and what the written agreement must say before any money changes hands.
Confirm QSA company status
Only a Qualified Security Assessor company can issue a Report on Compliance for a service provider. Check the firm's status and the named assessor on the PCI SSC's published listings before signing, and record the listing date and assessor name in your file. Ask whether the individual who will sign the Report on Compliance is the same person on the listing. A consultant that is not a QSA company can prepare you for an assessment, but it cannot issue the report that your customers will request.
Separate design from assessment
A firm that designs, configures or operates your controls should not also be the firm that tests them and signs the report. Ask any proposed QSA whether it has built, managed or monitored any part of your environment, and ask any consultant whether it plans to assess your work later. If the same firm does both, the assessment loses its independence, and your customers may refuse the Attestation of Compliance. Write the separation into the engagement letter so each party's role is clear.
Ask for service provider assessments
Assessing a service provider is different from assessing a merchant. Ask for examples, described in anonymized terms, of service provider Reports on Compliance the firm has completed, including multi-tenant hosting, managed firewalls, or vendor remote access into customer environments. Ask how the team tests the responsibility matrix you give customers, and how it handles customer requests for evidence of Requirement 12.9 duties. A firm that has only assessed merchants may miss how your access into customer systems changes the assessment.
Define written scope and deliverables
Ask for a written scope that lists every service you provide, every customer environment you can reach, every administrative jump host and remote access tool, and every internal system that supports those services. Under PCI DSS, the scope of a service provider assessment includes all people, processes and technology involved in providing the service, so an incomplete scope produces an incomplete report. The agreement should also name the deliverables, including the Report on Compliance, the Attestation of Compliance, and any evidence packs for customers, plus who pays for re-testing if a finding is open.
Clarify who prepares the evidence
Preparing evidence and assessing it are separate tasks. Ask the consultant which artifacts it will build, such as network diagrams, access review records, MFA configuration exports and remote access logs, and which artifacts your team must produce from its own systems. Ask the assessor which samples it will request and over what period. Confirm that the same question applies to any open-source tooling you deploy for logging, access control or vulnerability scanning, because the assessor will test whether those tools operate as described.
Questions to ask before signing
Before signing, ask four questions: Is the firm on the current QSA listing, and who is the signing assessor? Which of our controls have you designed, operated or monitored? How many service provider Reports on Compliance has the team completed in the last few years? What is excluded from scope, and what changes the fee? Ask the same questions of any consultant, and request the answers in writing. Hesitation on any of them is a reason to pause before committing to a timeline.
How DeployOpen prepares an MSP's systems and evidence
DeployOpen works as an implementation partner for managed service providers that need their own administrative tooling and vendor access paths to meet the requirements that apply to them. Under a written, fixed scope, DeployOpen scopes, configures and hardens self-hosted open-source platforms inside the MSP's own cloud accounts, data centers or networks. Typical work includes the jump hosts or remote access gateways that third parties use, MFA enforcement for remote and administrative access, per-vendor account provisioning with time-limited enablement, session logging, and the monitoring that catches unexpected vendor activity. The MSP owns its controls. DeployOpen configures the systems and assembles the evidence, but it does not decide whether a control is adequate for the MSP's risk.
Evidence preparation is where the work becomes assessable. Before the assessment, the MSP should ask for a deliverable that maps each configured control to the requirement it supports, names the system and owner, and points to the log, configuration export or ticket that shows the control operating over time. Confirm with your QSA which artifacts they will sample, for example vendor account enablement records, MFA configuration exports, and review records for vendor sessions. Also confirm which requirements the MSP will mark as its own and which it will share with customers, since that split drives the written acknowledgments and the evidence customers can request.
Only an independent Qualified Security Assessor issues a Report on Compliance or an Attestation of Compliance for the MSP. DeployOpen does not perform the assessment, does not sign any attestation, and does not guarantee a result. Before engaging anyone, the MSP should confirm that the QSA is independent of the implementation work, agree in writing on what DeployOpen will deliver and what the MSP's staff must still perform, and ask the QSA which evidence formats they accept. Pricing follows from the written scope, so the quote should list each system, each control area, the documentation to be produced, and the ongoing tasks the MSP will run after handover.
