Aventura, Florida · serving clients across the United States (305) 404-9404Toll-free (800) 767-8566Emergency? Get a call within 1 hour
Defense manufacturing, small contractor Illustrative engagement

A CUI contractor maps its cloud provider's customer responsibility matrix into its system security plan before the assessment

A precision-machining and electronics contractor of about 85 staff in South Florida, a subcontractor to larger defense primes, a leader in its segment.

Scale
110 NIST SP 800-171 requirements, 1 cloud environment holding CUI, 1 provider matrix, 21 requirements inherited, 38 shared, 51 the contractor's own, 6 gaps found
Engagement
Three weeks to map and document, two weeks to close gaps, then a mock assessment before the scheduled one

The challenge

The contractor had moved its controlled unclassified information (CUI) into a cloud environment from a provider that is authorized at the FedRAMP Moderate level, and its first draft of the system security plan said for dozens of requirements that the cloud provider handles it. The statements had no source. The provider publishes a customer responsibility matrix that says, requirement by requirement, what the provider does, what the customer does and what is shared, but nobody at the contractor had read it against the plan. A prime contractor had asked for evidence ahead of a CMMC Level 2 assessment, and an assessor will ask how each inherited control is known to be inherited.

Moving controlled unclassified information to a cloud provider moves some of the work and none of the accountability. The provider runs the data center, the hardware and much of the platform. The contractor still answers for who can sign in, what devices connect, how the data is handled and whether the provider's part can be shown. The document that divides the work is the customer responsibility matrix.

Many first drafts of a system security plan treat the matrix as a reassurance. The better use is to treat it as a source. Each of the 110 requirements in NIST SP 800-171 is placed against the provider's row and sorted into inherited, shared or the contractor's own, and the plan then cites the row, the document and its version. That turns the phrase the provider handles it into a statement an assessor can check.

The mapping is also where scope problems appear. In this illustrative case, the cloud environment was properly described, but CUI also moved through email that lived in a different tenant, outside the provider's matrix. A plan that only described the enclave would have missed it, and an assessor looking at where CUI actually goes would not have.

A mock assessment, run by someone who did not write the plan, is the last step. It tests the plan the way an assessor will, by examining documents, interviewing owners and checking systems, and it shows where an answer is a belief and not a record. The goal is a contractor that can explain its own environment, with the provider's part and its own part kept clearly apart.

What our team delivered

  • A scoping review first: which systems store, process or transmit CUI, which protect them, and which cloud services sit in the data path. The provider's authorization boundary was confirmed from its current package, with the date and version recorded, and the review found that CUI also travelled by email through a commercial mail tenant that sat outside the provider's matrix
  • The provider's customer responsibility matrix mapped to all 110 requirements of NIST SP 800-171 Rev. 2, one row per requirement with three columns: what the provider implements, what the contractor implements and the evidence for each. The result was 21 requirements fully inherited, mostly physical protection of the data center and parts of media handling, 38 shared and 51 the contractor's own
  • The SSP rewritten requirement by requirement. An inherited control cites the matrix row, the provider's document title and version and the date the contractor last reviewed it. A shared control states both halves, for example that the provider supplies validated cryptographic modules for the service while the contractor enforces their use on its endpoints and VPN, and that the contractor's multifactor authentication covers every user of the environment
  • The six gaps the mapping exposed, each with an owner and a due date in the plan of action: CUI email moved into a compliant mail environment, endpoint disk encryption evidence for two laptops, an unreviewed administrator group in the cloud tenant, a missing log-review record, an incident-reporting contact list that did not include the provider and a process for reviewing the provider's matrix after each update
  • Contract and incident-reporting alignment: the provider's agreement was checked for the clauses that DFARS 252.204-7012 requires of a cloud provider handling CUI, including reporting of incidents, preserving images for forensic analysis and access for DoD investigators. A 72-hour reporting path was rehearsed with the provider's security contact named in the plan
  • Evidence collection for the shared and customer controls: configuration exports, access lists, sign-in policy screenshots, vulnerability scan results and dated review records, filed under the same requirement numbers as the plan so that an assessor can follow a requirement to its proof in one step
  • A mock assessment by a team member who had not written the plan, sampling 30 requirements across all families and testing each answer by examining the document, interviewing the owner and checking the system. A repeatable calendar: provider matrix check every quarter, evidence refresh every six months and a plan review at each change of the environment

Result

The mock assessment found 4 issues across the 30 sampled requirements, all of them fixed, against the 17 weaknesses the same sample would have turned up against the first draft. Every inherited or shared requirement in the plan now names its source row and document version, and an assessor can trace an answer from the plan to the provider's statement and to the contractor's own evidence. Inheritance is not a pass: the contractor remains responsible for confirming the provider's status and for its own half of every shared control, and the plan describes how that is done. The assessment outcome belongs to the assessor, and this case does not predict a score. This is an illustrative engagement that describes the kind of work our team does; details are composite.

Get this for your company

Related services with fixed prices and a written scope.

Initial assessment of public endpoints

What an attacker can see and reach from the internet: your domains, mail, websites, remote access and cloud exposure.

Report within 5 business days of kickoff

$1,000 per assessment

Details

Clayton Secure program

One monthly program that bundles monitoring, patching, backups, email protection and security awareness for your whole team. Priced per team member.

Onboarding starts within 10 business days

$150 per team member, per month

Details

Show 2 more

Cloud security review

A review of one Microsoft 365, Azure, AWS or Google Cloud tenant against recognized benchmarks.

Report within 7 business days of read-only access

$2,800 per tenant

Details

Cloud management

We run your Microsoft 365, Azure, AWS or Google Cloud environment: access, cost, patching, backup and security settings. Priced per month for one tenant.

Onboarding within 15 business days

$1,900 per tenant, per month

Details

After you purchase, we contact you within 1 hour, any time of day or night, to start onboarding.

No payment is taken online. When we call you within the hour we confirm the scope and send an invoice (ACH, card or crypto).

Super Intelligence data flow

Every request is classified by sensitivity, so confidential data stays on models inside your walls while routine work can use the best frontier AI.

Super Intelligence data flowEmail, documents, phone calls, ERP and CRM records and sensor data enter a secure gateway that classifies each request by sensitivity. Sensitive requests are answered by local models inside the firewall, internal ones by a private cloud, and general ones by frontier models from leading US AI labs. Results flow back into ERP, CRM, dashboards and to people.SOURCESGATEWAYMODEL TIERSYOUR SYSTEMSEmailDocumentsPhone callsERP / CRMSensorsSecuregatewaysorts bysensitivityLocal modelsIn your firewallPrivate cloudYour own tenantFrontier modelsleading US AI labsERPCRMDashboardsPeopleSensitive: stays localInternal: private cloudGeneral: frontier model

The evidence pack and who asks for what

Twelve artefacts a firm can show about its AI use, and the party that most often asks for each: an insurer at renewal, an auditor or client questionnaire, or a regulator. A typical pattern only; the exact list depends on the policy, framework and sector.

The evidence pack and who asks for whatTable of twelve evidence artefacts against three audiences: insurer, auditor or client questionnaire, and regulator. Inventory, human approval points, a named owner and an incident plan are usually asked by all three. Payment procedure and drill records are mainly an insurer topic. Action and prompt logs and test records matter most to auditors and regulators.Twelve artefacts, three audiencesUsuallySometimesRarelyInsurerat renewalAuditoror client questionnaireRegulatoror supervisor1. AI inventory: every tool and agent2. Agent permission matrix3. Action and prompt logs4. Human approval points5. Test and evaluation records6. Payment verification procedure7. Payment drill record8. Named accountable owner9. Supplier and model list10. Data-use and retention rules11. Incident and rollback plan12. Staff training recordQualitative pattern, not a checklist from any one insurer or regulator.

Do you know if your company is safe?

Speak with a security engineer today. The first assessment call is free and confidential.

CallFree assessment