In this article, MSPs will:
- Identify hot topics driving a decision to pursue CMMC opportunities.
- Answer questions designed to reveal their MSP’s overall maturity.
- Uncover compliance talking points for strategic conversations with executive leadership.
Are CMMC opportunities right for you?
As the Cybersecurity Maturity Model Certification (CMMC) rolls out for defense contractors, thousands of MSPs are beginning to wonder whether they should take on CMMC opportunities or avoid highly regulated clients.
Following countless discussions with MSPs of all sizes, a repeated set of patterns and considerations have emerged in areas like governance, HR practices and documentation.
7 areas MSPs should analyze before delving into CMMC opportunities
Before your MSP decides to pursue CMMC opportunities, ask yourself several questions to gauge overall alignment with regulated data and assessment requirements.
1. Governance: Becoming a highly auditable organization
- Q: Do we have a compliance owner (not “the tech lead”), with the business authority to enforce processes even when it slows delivery?
- If the CMMC effort doesn’t have executive sponsorship and resourcing (calendar blocks, training budget, a lab environment, etc.), then it’s just a good idea and not your “new normal.”
- Q: Does following policy and procedure result in repeatable evidence? Or do we rely on individual heroics?
- Individual behavior shouldn’t be driven by those who complain the loudest or how big the fire is. If brute force efforts are the ceiling, consistent practices are the foundation for CMMC activities.
- Q: Are our vendors prepared to help us meet CMMC requirements?
- CMMC requires MSPs to provide a cohesive view of who does what in the form of a Shared Responsibility Matrix (SRM). If your vendors can’t describe how to meet 800-171 requirements using their tools, you’ll be on your own.
2. Data flows: How well you know the ins and outs of your support stack
- Q: Have we identified how customers’ CUI could end up in our systems?
- Do you know which file extensions contain CUI in customer environments?
- How many of your tools can consume, upload or transfer those files to unapproved platforms?
- Q: Can we prevent security tools from becoming a CUI Asset?
- If you claim you don’t touch CUI, enforce guardrails so techs don’t end up with CUI files in tickets, uploaded to your EDR or accessed by the SOC from a customer’s device.
- Q: Is there a formal agreement between you and your customer?
- A formal agreement should document the most sensitive data (i.e., Security Protection Data) that your MSP tools are approved to handle. It also must capture any controls that prevent unapproved data transfers from customer systems to MSP infrastructure.
3. People risk: HR controls that match tech controls
- Q: Can you do background screening, onboarding/offboarding rigor, access reviews, and enforce training?
- Don’t be the reason your clients can’t prove who has authorized access to their systems. Make background checks, new user training, and account reviews “table stakes” for being on the CMMC support team.
- Q: Can you operate with clear foreign access/export-control constraints when customers have ITAR/EAR-sensitive work (even if the immediate driver is CMMC)?
- With so many defense contractors handling technical data, it’s critical to make sure that no foreign nationals (people who aren’t U.S. persons) can access export-controlled files for servicing these clients.
4. Identity and access: can you practice what you preach?
- Q: Do we already operate with named accounts and MFA everywhere for admin work?
- Proving who took a privileged action is foundational for multiple requirements your clients must meet. An MSP’s internal authentication and session logs might be needed to rule them out as the source of an incident or malicious action.
Ryan Bonner and Jeremy Young
- Proving who took a privileged action is foundational for multiple requirements your clients must meet. An MSP’s internal authentication and session logs might be needed to rule them out as the source of an incident or malicious action.
- Q: Can we eliminate an everyone-is-a-global-admin/domain-admin culture?
- Implementing least privilege for your clients doesn’t matter if your techs play by different rules. Use time-bound elevation for everyday support activities, and reserve “system-high” roles like global admin and domain admin for situations that require approval to activate.
5. Change management: Being fast and principled
- Q: Is every meaningful change ticketed, approved, implemented and attributable with artifacts retained?
- Highly audited environments punish undocumented changes. Document a strong security “why” behind system changes and have clients preapprove changes that improve security.
- Q: Do we have baseline configurations that are consistent across clients?
- The “desired state” of client systems should be standardized, not bespoke. Most MSPs have a “gold image” for operating systems, but don’t always know what’s in it (or why). A good baseline tells you what each setting is “worth” in NIST 800-171A.
6. Logging and evidence: Producing proof on demand
- Q: Can we provide logs, configurations, access records, vulnerability remediation records, IR records and training records quickly and consistently?
- In regulated defense work, saying, “We do that,” is worthless without evidence. Plan to deliver monthly reports, weekly activity digests and as-needed proof that you’re holding up your end of the service-level agreement (SLA).
- Q: Do we have synchronized time stamps and multiple log sources, so investigations and audits are not a scramble?
- NIST 800-171 requires correlated system logs. It’s also a huge enabler for continuous security control assessments and post-incident evidence collection.
- Q: Are our tools (identity, RMM, PSA) configured so evidence is reliable and immutable?
- An unmodifiable audit trail (i.e., single sign-on logs in Entra ID, a SIEM with cold storage retention) reduces the chance of gaps in your compliance narrative when sampled or requested by an assessor.
7. Incident response reality: Meeting contractual reporting obligations
- Q: Can we detect incidents quickly enough that “72 hours from discovery” isn’t a trap?
- DFARS 252.204-7012 defines “rapidly report” as within 72 hours of discovery of a cyber incident, plus related obligations (malware submission, damage assessment support). Always know who’s on call to respond when potential incidents are detected. Don’t let nights or weekends be the reason why your client failed to meet contractual reporting obligations.
- Q: Are we prepared to coordinate with the customer on reporting workflows and preserve evidence?
- Chances are your team will complete the initial incident report form clients will submit to the Department of Defense Cyber Crime Center (DC3).
Jeremy Young is director, community at Huntress, and Ryan Bonner is founder and CEO of DEFCERT. Read more about Huntress and DEFCERT’s compliance playbook for MSPs.
Featured image: AI generated by Copilot
