Which compliance framework should an MSP pursue first?
The first investment depends on who is asking and what proof they accept. An MSP with EU customers, US defense contractors and banks in its client base faces four different demands, and NIS2, CMMC, DORA and customer-driven SOC 2 or ISO 27001 each produce a different kind of proof. NIS2 creates no certificate of compliance: national authorities supervise through inspections, security audits, information requests and fines, so your evidence is whatever you can show an inspector. ISO/IEC 27001 is certified only by accredited certification bodies, and DeployOpen does not issue that certification. A SOC 2 report is an attestation issued by a CPA. Start by listing which customer contracts name a proof type, then map each one to the regime or report that produces it.
Pursue SOC 2 first when your buyers are mostly US enterprises that want a service auditor's opinion on your controls. A Type 1 report covers the system description and the suitability of control design as of a date. A Type 2 report adds an opinion on operating effectiveness over a period, so it needs an observation window of operating evidence before the auditor can issue it. Pursue ISO/IEC 27001 first when tenders or customers outside the US ask for an accredited certificate, or when you want a management system that certification bodies can assess against a fixed scope. Under ISO/IEC 17021-1, certification runs on a three-year cycle with at least one audit in every calendar year. Confirm with your key customers which of these they will accept before committing.
How NIS2, CMMC, DORA, SOC 2 and ISO 27001 differ for a provider
This table compares five frameworks by who they reach, what they require of a managed service provider, and what proof each produces. Read the first two rows to see whether the framework applies to you directly or only through customer contracts, then use the proof row to decide what to invest in first.
| Dimension | What it asks of the provider | Proof it produces |
|---|---|---|
| NIS2 | Reaches managed and managed security service providers directly under Annex I (ICT service management) when they meet the size-cap rule. Recital 86 calls for increased diligence in selecting managed security providers. | No certificate. National authorities supervise through inspections, security audits, scans, information requests and fines (Articles 32 to 34). |
| CMMC | Applies to a provider only as an external service provider when it processes, stores or transmits CUI or security protection data on its assets (32 CFR 170.4). Customers flow requirements down through contracts. | Level 2 certification assessments by C3PAOs and Level 3 by DCMA DIBCAC (32 CFR 170.17 and 170.18). Mandatory for the contracts that require it. |
| DORA | Reaches ICT third-party providers mainly through the contracts financial entities must sign (Article 30). Designated critical providers face direct ESA oversight (Articles 31 to 44). | No certification scheme. The only authority-issued attestation is that a threat-led penetration test met the requirements (Article 26(7)). |
| SOC 2 | Voluntary. Customers ask for it, and the provider describes its system and controls against the Trust Services Criteria. Scope is set by the provider and its auditor. | CPA-issued report. Type 1 covers the system description and control design as of a date. Type 2 adds an opinion on operating effectiveness over a period. |
| ISO/IEC 27001:2022 | Voluntary unless a contract requires it. The provider builds an information security management system and is audited against the standard's requirements and its Annex A controls. | Certificate issued by an accredited certification body, not by ISO. Certificates run on a three-year cycle with annual audits. |
| Mandatory or voluntary | NIS2 and DORA bind through national law and EU law respectively. CMMC binds through US federal contracts. SOC 2 and ISO 27001 are market-driven unless a customer contract requires them. | Confirm with your customers and regulators which obligations apply to your specific services before choosing a certificate or report. |
Why NIS2 puts managed service providers in scope directly
Under NIS2, a managed service provider is not just a supplier to regulated customers. It can be a regulated entity in its own right. Annex I of Directive (EU) 2022/2555 places ICT service management in scope, and managed service providers and managed security service providers fall within that category when they meet the directive's size-cap rule. Recital 86 goes further and calls for increased diligence when essential and important entities select managed security service providers. Confirm your own size position against the size-cap test with counsel before assuming you are outside scope, because the answer decides which obligations you carry directly.
Once in scope, the classification matters. Entities are sorted as essential or important under Article 3. Both groups carry the same risk-management measures under Article 21 and the same incident reporting duties under Article 23, but essential entities face ex ante supervision, meaning oversight before any failure, while important entities face ex post supervision, meaning scrutiny after an incident or evidence of non-compliance (Articles 32 and 33). Commission Implementing Regulation (EU) 2024/2690 sets the technical and methodological requirements of the Article 21(2) measures for managed and managed security service providers. Map your controls to that regulation first, because it is the text an inspector will test against. ENISA's non-binding guidance of 26 June 2025 adds examples of evidence and mappings to ISO/IEC 27001:2022 and NIST CSF 2.0, which is the most practical starting point for building that evidence file. The Commission's proposal COM(2026) 13, which would add a small mid-cap category, still needs approval from the European Parliament and the Council, so plan on the current text.
The practical consequence is that no certificate closes the question. NIS2 creates no certificate of compliance. National competent authorities check compliance through inspections, security audits, security scans, information requests and administrative fines (Articles 32 to 34). A customer's ISO 27001 certificate or SOC 2 report can support your position, but it will not replace evidence that your own controls operate as Implementing Regulation 2024/2690 describes. Ask your national authority which supervisory approach applies to your entity and what documentation it expects, and keep incident and control records in a form you can produce on request.
How CMMC treats a provider as an external service provider
Under CMMC, an MSP is not automatically in scope because it works with a defense contractor. The provider's position depends on whether its own systems touch CUI or security protection data, and that answer drives which assessment it may need and what its customers will ask for.
Test against the ESP definition
Start with the definition in 32 CFR 170.4, which covers external people, technology or facilities used to provide or manage IT or cybersecurity services. Your staff, tools and facilities that run a client's IT may fall under it. Write down every service you deliver to a defense contractor and map who operates it, so the definition test is applied to a documented service list rather than memory. Ask the customer whether it has already classified you in its CMMC scoping.
Check where CUI and security data flow
A provider counts as an ESP only if CUI or security protection data, such as log and configuration data, is processed, stored or transmitted on its assets. A help desk that never sees CUI and a SIEM operator that collects client logs land in different places. Map the data paths for each managed service, including backups, remote access sessions and ticketing attachments, because a single copy on your platform can change the answer.
Plan for a Level 2 C3PAO assessment
Where a provider's assets are in scope for a Level 2 requirement, the assessment is performed by a C3PAO authorized or accredited by The Cyber AB. Confirm with your customer which CMMC level applies to the contract, then confirm with a C3PAO how it will scope your environment. Ask whether it will assess your managed services as a separate boundary or as part of the customer's assessment, because that choice drives both preparation work and the evidence you must produce.
Recognize the Level 3 DIBCAC route
Level 3 certification assessments are performed by DCMA DIBCAC rather than a C3PAO. An MSP that supports a Level 3 program needs to know that the government assessor, not a private firm, will review its assets and controls. Ask the customer which contracts require Level 3 and whether the provider's services fall inside that boundary before you commit to tooling or staffing changes that depend on the outcome.
Assess your own assets as part of the boundary
Where your systems store, process or transmit CUI or security data for a customer, those systems can become part of the customer's assessment boundary. Your remote management platform, log collectors and ticketing system may need to meet the same requirements as the customer's own systems. Inventory these platforms early, document which ones handle customer data, and ask the customer how it intends to show that your assets are covered in its System Security Plan.
SOC 2 or ISO 27001 when customers ask for proof
A SOC 2 is an examination report, not a certificate. A CPA firm performs it under AT-C section 205 of the AICPA attestation standards, which is an assertion-based engagement: the service auditor must obtain written representations from management about the system and its controls. The examination uses the 2017 Trust Services Criteria, which contain 61 criteria in total, including 33 common criteria. The common criteria cover security (CC1 to CC9) and apply to every SOC 2, while availability, processing integrity, confidentiality and privacy are added only when they are in scope.
- Type 1 versus Type 2: A Type 1 report covers the system description and whether control design was suitable as of a date. A Type 2 report adds an opinion on operating effectiveness over a period, which is what most procurement teams ask for.
- Distribution: A SOC 2 report is generally restricted to specific users, so customers sign an NDA or receive it through a trust portal.
- SOC 3: A SOC 3 covers the same categories in less detail and is a general use report that can be freely distributed, which suits public trust pages.
- Who asks for it: US enterprise buyers and service organizations whose customers expect a CPA-issued report over operational controls.
- Scope choice: The categories in scope, and the subservice providers carved out, shape what the report covers.
Before committing, confirm with the CPA firm which categories, system boundary and period your customers expect, and whether they accept a carve-out for your own subservice providers.
ISO/IEC 27001 is a standard for an information security management system, and it is certifiable. ISO does not certify organizations; accredited certification bodies do. Accredited ISMS certification bodies operate to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. The current edition, ISO/IEC 27001:2022, has 93 controls in Annex A, grouped into organizational, people, physical and technological themes, and these are drawn from ISO/IEC 27002:2022.
- Accredited certificate: The output is a certificate from a body accredited for this scope, which you can check in the IAF CertSearch database.
- Three-year cycle: Under ISO/IEC 17021-1, the certification cycle lasts three years, with at least one audit in every calendar year, either surveillance or recertification.
- 2013 transition: Under IAF MD 26:2023, all certifications to ISO/IEC 27001:2013 had to expire or be withdrawn by 31 October 2025, so any older certificate you hold no longer counts.
- Who asks for it: European, global and public sector buyers who want a recognized, certifiable management system rather than a report.
- Scope statement: The certificate covers the scope you define, so customers should be told whether the managed service and its supporting tooling sit inside it.
Confirm with your certification body which edition, scope and accreditation status apply to your certificate before a customer relies on it.
The two proofs answer different questions. SOC 2 tells a customer how your controls were designed and, in Type 2, operated over a period, as judged by a CPA firm against criteria you help define. ISO/IEC 27001 tells a customer that an accredited body has certified your management system against a fixed control set, with periodic audits. Many MSPs receive requests for both, and the choice often follows the buyer's region, sector and procurement template rather than technical fit.
- Ask who is requesting: Note whether the request names a SOC 2 report, an ISO certificate or a generic assurance artifact.
- Check the period: A Type 2 report covers an observation window, while a certificate reflects the most recent audit cycle.
- Check the scope: Both proofs are bounded by a system or scope statement that must match the services you sell.
- Plan the evidence: Controls mapped once to the 2017 Trust Services Criteria and to the ISO Annex A controls reduce duplicated evidence work.
- Avoid substitution: A SOC 2 report does not replace an ISO certificate, and neither replaces a regulator's supervision of a managed service under NIS2 or DORA.
Ask prospects which proof their procurement policy names, and confirm whether an equivalent is accepted before starting either engagement.
Where the controls overlap and where they do not
The overlap between frameworks is real in the sense that published mappings exist, but a mapping is a reference tool, not a finding. The CIS Controls Navigator for v8.1 offers mappings to 30 frameworks and versions, including NIST CSF 2.0, ISO/IEC 27001:2022, SOC 2, CMMC v2.0, DORA and NIS2. NIST's CSF 2.0 Reference Tool export lists 363 Implementation Examples and informative references to standards that include ISO/IEC 27001:2022 and CIS Controls v8.1. Use these as a starting point for deciding which of your existing control evidence can serve more than one requirement. Before relying on any row, check the mapping's source and version, because NIST does not check the correctness of non-NIST mappings and listing a mapping does not imply endorsement.
A mapping shows where evidence can be reused, not that one audit satisfies another. ENISA is explicit that its NIS2 mapping to ISO/IEC 27001:2022 and NIST CSF 2.0 is not a measure of equivalence and does not assess whether a standard fully covers the regulation's requirements. For an MSP, the practical reading is that a SOC 2 Type 2 report may document access reviews, change management and incident handling that a NIS2 authority or a DORA customer will want to see, but the regulator or customer still decides whether those controls cover their specific obligations. HITRUST says its CSF harmonizes more than 70 authoritative sources on its framework page. That breadth is a claim to verify against the mappings you need, not a guarantee that each source is fully addressed.
The clearest example of a bounded reuse rule is in PCI DSS. A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment, but may reuse evidence from those audits after independently reviewing it, which can reduce duplicated evidence work. For a provider serving card-processing customers, this means a SOC 2 report saves effort only if the QSA is willing to review the underlying evidence, and the provider should confirm that scope, sampling period and system boundary match the PCI assessment before promising reuse. Ask each customer's assessor which evidence they will accept and in what form, and record the answer in the control matrix.
Sequencing SOC 2, ISO 27001 and regulatory proof
The sequence turns one control set and one evidence library into several proofs, so an MSP answers customer demands and regulatory duties without rebuilding its controls for each request. The exact order depends on the written contracts and the jurisdictions where each service line operates.
Map customers and contracts demanding proof
List every customer contract, tender and master services agreement that asks for a SOC 2 report, an ISO/IEC 27001 certificate, a CMMC level, DORA-style contractual clauses or NIS2 supply chain terms. Record the exact wording, the named framework, the proof type requested (report, certificate, questionnaire or audit right) and the service lines affected. The step is done when a single register shows each demand against the contract that imposes it, reviewed by the account owner and legal counsel.
Confirm which regulatory flow-downs apply
For each service line, confirm with counsel whether NIS2 applies to the provider directly through the size-cap rule, whether CMMC treats the provider as an external service provider because it processes CUI or security protection data, and whether DORA reaches the provider through contractual clauses that a financial customer must sign. Check the Implementing Regulation (EU) 2024/2690 and the national transposition law in each Member State where you operate, and confirm current status of any pending amendments. The output is a written applicability note per service line, signed off before any certification scope is chosen.
Choose the first attestation most customers accept
Compare the demands in the register and select the report or certificate that the largest share of customers and tenders will accept. A SOC 2 Type 2 report suits North American service desks and managed security operations, while an ISO/IEC 27001 certificate suits customers that ask for a certifiable management system in Europe and elsewhere. Ask prospective customers in writing whether a Type 1 report or a certificate is acceptable. The step closes with a documented decision, the scope statement and a named owner for the chosen proof.
Build one control set and evidence library
Map the chosen framework's controls against the regulatory obligations and the other framework you plan to pursue, using official mappings where they exist, such as the ISO/IEC 27001:2022 and NIST CSF 2.0 references or the CIS Controls Navigator. Record where one control satisfies several requirements and where a gap remains. Assign each control an owner and a recurring evidence source, such as access reviews, change tickets and backup restore tests. The step is complete when every control in scope has one evidence location that both the auditor and the regulator-facing team can reference.
Reuse the library for the second path
Extend the same control set to the second proof, adding only the requirements the first framework does not cover, such as CMMC practices for CUI processing or the ISO-specific clauses for the management system. Confirm with the certification body or the assessor what evidence they will accept from the existing library and where they expect a separate record. Track the reused evidence and the additions in one change log. The step is done when the gap list for the second path is short, owned and scheduled against the customer demands in step one.
Plan the observation window or surveillance cycle
For a SOC 2 Type 2 report, agree with the CPA firm the observation period and the evidence the service auditor will sample, and confirm that management can produce the written representations the examination requires. For ISO/IEC 27001, confirm the certification cycle and the surveillance audits your certification body will schedule, since ISO/IEC 17021-1 expects an audit in every calendar year. For any regulator-facing duty, confirm with the authority how inspections and information requests will be handled. The step closes with a dated calendar of audits, observation periods and evidence reviews kept by a named owner.
Keep proof current after issuance
Once a report or certificate is issued, track its validity, distribution limits and renewal dates, and check whether each customer's contract requires notice of changes in scope or control failures. Use the evidence library for quarterly control testing so that the next examination or surveillance audit starts from current records. Review the register from step one whenever a customer adds a service line or a regulation changes. The step is done when the review log shows each proof's status, expiry and open exceptions.
Who assesses each path and what is issued
This table shows who checks each framework's obligations for an MSP or MSSP, what the assessment produces, and how often it recurs. Read it to see which outputs are certificates, which are reports, and which are supervisory actions with no certificate at all.
| Framework | Who assesses | What is issued | Cycle |
|---|---|---|---|
| NIS2 | National competent authority in each Member State | No certificate of compliance; inspections, security audits, scans and information requests | Ongoing supervision; ex ante for essential entities, ex post for important entities |
| CMMC Level 2 | C3PAO authorized or accredited by The Cyber AB | Certification assessment result tied to the provider's assessed environment | Assessment cycle set by the CMMC program; confirm current terms with the sponsoring customer |
| CMMC Level 3 | DCMA DIBCAC | Certification assessment result | Confirm the current cycle with the contracting authority |
| DORA (ICT providers to financial entities) | Competent authorities supervise the financial entity; ESAs oversee designated critical providers | No certification scheme; the only authority-issued attestation is for a threat-led penetration test under Article 26(7) | Set by the contractual and supervisory arrangements of each financial entity |
| SOC 2 | CPA firm acting as service auditor | Type 1 report (design as of a date) or Type 2 report (design and operating effectiveness over a period) | Usually annual for Type 2; the report itself is the evidence customers receive |
| ISO/IEC 27001 | Accredited certification body | Certificate of conformity to the ISMS standard | Three-year certification cycle with at least one audit in every calendar year |
What do MSPs ask before pursuing these frameworks?
Does NIS2 require a managed service provider to get a certificate?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. An MSP in scope should expect to show its risk-management measures and incident reporting to its national authority, and to its customers, as evidence rather than a certificate. Because NIS2 is a directive, the exact obligations and supervision depend on the national transposition law in each country where the MSP operates, so confirm the local rules with counsel or the competent authority.
Does an MSP need CMMC certification to serve defense contractors?
Only if the MSP is an external service provider that processes, stores or transmits CUI or security protection data, such as log and configuration data, on its assets. Under 32 CFR 170.4, an external service provider counts for CMMC only in that case. An MSP that handles that data for a defense customer should confirm with the prime contractor which CMMC level applies to its own environment and whether a C3PAO assessment is required. An MSP that never touches that data on its assets may still be asked for supporting evidence in the contract, so check the flow-down clauses.
What drives the cost and effort of pursuing these frameworks for an MSP?
Cost follows scope, not a fixed price list. The main drivers are the number of customer environments and in-scope assets, the number of customers asking for a report, how many services are in the system description, and how mature the current evidence is. Costs split into one-time work (gap analysis, control design, policy writing, tooling changes and the first audit) and recurring work (surveillance audits, annual reports, evidence collection and control operation). Ask any quote to itemize these components, state assumptions about asset counts and customer counts, and separate audit fees paid to the independent auditor from DeployOpen's readiness and implementation fees. No figures are given here because none were supplied for this topic.
What does a SOC 2 Type 2 observation period require from our staff?
A Type 2 report adds an opinion on operating effectiveness over a period, so controls must run consistently for the whole observation window, not just on a single date. Staff must follow access reviews, change approvals, monitoring, incident handling and onboarding or offboarding steps every time, and leave evidence of each run, such as tickets, approvals and logs. Management must also give the auditor written representations, under AT-C section 205, about the system and controls. The practical demand is steady, documented execution by the people who run customer environments, so plan for that workload before the window starts.
Can our MSP do the framework readiness work in house?
Often yes, if the team has someone who can map the framework's criteria to existing controls, write the system description and run an internal gap review. The work that usually takes the most time is turning day-to-day operations into repeatable evidence, and that is hard to do while also delivering customer services. Consider which parts you can own, such as the asset inventory, access reviews and change records, and which need an outside view, such as a gap assessment or an independent readiness review. Note that DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications, so an independent auditor or certification body is still required.
How do we ask for a written quote for a fixed-scope readiness engagement?
Start with a written scope that names the frameworks, the customer environments and services in scope, the number of in-scope assets and locations, the evidence you already keep, and the deliverables you expect. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list, so the quote follows from that scope. Ask for the work broken into phases, the deliverables for each phase, the assumptions behind effort, what the client must provide, what is excluded (such as auditor fees), and whether ongoing support or retainers are priced separately.
Which proof should an MSP request from its own suppliers?
Ask for the proof that matches the risk each supplier brings to your customer environments. Typical requests include a current SOC 2 Type 2 report or ISO/IEC 27001 certificate from the supplier, with the scope statement and the period covered, plus the supplier's list of subprocessors and evidence of MFA for accounts that reach customer systems. CISA's advisory AA22-131A recommends treating such accounts as privileged. Read a SOC 2 report's system description and any complementary user entity controls, because they define what you must do yourself. Confirm whether the supplier's certificate is issued by an accredited certification body, and check the supplier's contractual obligations in writing.
What no certificate can promise an MSP
A SOC 2 report, an ISO/IEC 27001 certificate or a CMMC result describes a defined scope at a defined time. A SOC 2 Type 1 report covers the system description and control design as of one date, and a Type 2 report adds an opinion on operating effectiveness over a stated period. Neither covers service lines outside the system description, new platforms added after the period closed, or an incident that happens next month. An ISO certificate covers the scope the provider defined for its information security management system, and certification bodies audit it within a three-year cycle with at least one audit each calendar year. A CMMC Level 2 result covers the assessed environment only. Before you promise coverage to a customer, check which services and tenants the report names, and which fall outside it.
Two regulatory items are still moving, so treat them as open questions rather than settled facts. On 20 January 2026 the Commission proposed targeted amendments to NIS2 in COM(2026) 13, including a new small mid-cap category. The proposal needs approval by the European Parliament and the Council, so confirm its status before you scope your EU customer obligations. The AICPA also exposed proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029. Ask your SOC 2 auditor how any adopted revision would change the report you buy and when it would take effect for your engagement. Journal of Accountancy coverage of the proposed attestation changes is a natural next read.
The value of a report lies in the evidence trail behind it. A Type 2 examination depends on written management representations, a system description the auditor evaluated, and samples of control operation across the period. Keep those artifacts organized: the service inventory, the asset and tenant lists, change records, access reviews, incident tickets and the subservice provider assurance you rely on. Customers and regulators ask for that trail when a question arises after the certificate date, and it is the part you control. Plan an evidence owner for each control and a quarterly check that the scope in your report still matches what you operate.
How DeployOpen prepares an MSP for both paths
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares systems and evidence for compliance assessments. We do not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which services, customer environments and tooling are in the MSP's own infrastructure.
- Scope records which external assessor or certification body will issue any report or certificate, and at what stage.
How we build
- We implement and harden the self-hosted platforms that hold the MSP's management, logging and access controls.
- We map existing controls to the framework requirements the MSP has chosen, so evidence is gathered once where mappings allow.
- We test the built controls with security testing before the assessor's fieldwork begins.
How we hand over
- Deliverables include configuration records, control descriptions and evidence packs the MSP's auditor can review.
- Runbooks cover multi-factor authentication, privileged access and customer-account administration as designed.
- We document the gaps we found and the owner and steps needed to close each one before handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover evidence refresh for periodic assessments, such as a SOC 2 Type 2 observation period.
- Support scope and cadence are agreed in writing, with the MSP keeping responsibility for its own compliance decisions.
