Does CMMC apply to a machine shop that receives drawings?
If a prime or buyer has sent your shop drawings or specifications under a DoD contract, CMMC Level 2 will typically apply to the systems that store, process or transmit those files. The reason is the controlled technical information on them. DFARS 252.204-7012 defines technical information to include engineering drawings, associated lists and specifications, and it covers those that carry distribution restrictions under DoD Instruction 5230.24. Whether a given file is controlled depends on its distribution statement and the contract, so the first task is to read the markings on what you received. The requirement itself comes from the contract clause and 7012, not from CMMC alone. Level 2 is the 110 requirements of NIST SP 800-171 Rev. 2, which the CMMC rule incorporates. The answer still varies with where the files live, which assets touch them, and whether your contract carries the clause at all.
Your shop owns its controls. An implementation partner, such as DeployOpen for self-hosted open-source platforms, can prepare systems, configurations and evidence, but it does not certify you. Only a C3PAO for a certification assessment, or the government in its own processes, issues that outcome. Timing also matters. On 13 July 2026 the Department of War suspended CMMC Phase II, which had covered Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings and the DFARS 252.204-7012 obligations remain in force, according to the Department of War release on the suspension. Confirm the current status of your specific contracts with the contracting officer before you plan.
What a manufacturer must confirm before scoping
Before anyone draws a CMMC boundary, a manufacturer needs to know which contracts bring CUI into the shop and where that information actually sits. The six checks below run in order: contracts first, then the documents, the systems that hold them, the people who touch them, and the paperwork that already claims a score.
Contracts carrying DFARS 7012
Start with the contract file, not the shop floor. Look for DFARS 252.204-7012 in each prime contract and subcontract, and note which ones also flow down the CMMC clauses. A contract without the clause may still carry CUI, so pair this check with a review of the statement of work and any technical data package. Record the contract number, the clause date and the owner of each agreement, because scoping decisions follow from this list.
Drawings and specifications marked as CUI
Pull the drawing and specification register for each contract and check the distribution statements and CUI markings. Controlled technical information is technical information with military or space application that carries access or dissemination controls, which typically means distribution statements B through F under DoD Instruction 5230.24. Information lawfully public without restriction is excluded. Mark every drawing set as either controlled or not, and flag any unmarked item that your customer has told you is controlled.
Where CUI lives in the shop
Trace each controlled file to every place it is copied: the ERP and PLM, CAD vaults, engineering laptops, email attachments, shared drives, and cloud sync folders. Engineers often keep local copies that never appear in an inventory. Produce a data-flow map showing how a drawing gets from the customer portal to the machine controller, since that path decides which systems fall inside the Level 2 boundary.
People and subcontractors with access
List every employee, temporary worker and subcontractor who can open a controlled file, including people who only print, machine from, or receive a PDF. Compare that list against your access groups in the directory and the CAD vault. Confirm which subcontractors hold their own copies, because each one that stores or processes CUI must be addressed in your flowdown and your own assessment scope.
Current system security plan
Check whether the shop has a system security plan that describes the systems that store, process or transmit CUI, the boundary around them, and how each NIST SP 800-171 Rev. 2 requirement is met. Confirm the plan is dated, signed and reflects today's network, not last year's. Assessors also look for plans of action and milestones where requirements are not yet met, so note which gaps you already know about.
Current SPRS entry and score
Find the score posted in the Supplier Performance Risk System for your CAGE code and confirm it matches what your SSP would support today. Check the date of the last posting and whether the affirmation is current. A score that claims full compliance without matching evidence is a risk, so reconcile the number against your SSP line by line before any new scope is drawn. Ask your contracting office which posting they will accept.
How shop-floor OT and test equipment are scoped
CUI assets are the systems that store, process or transmit controlled unclassified information, such as the CAD and PLM servers, engineering workstations and file shares that hold drawings and specifications. Under 32 CFR 170.19(c), these assets are assessed against all Level 2 requirements, so they carry the full weight of the assessment. For a machine shop, the practical question is which devices ever open a controlled drawing, not which devices are on the factory network.
- Drawing repositories: Document management or PLM servers that hold CUI are CUI assets wherever they run.
- Engineering workstations: Any workstation where an engineer opens, edits or prints controlled data is in scope for every requirement.
- Print and scan paths: Print servers and multifunction devices that handle CUI files need to be recorded as part of the CUI boundary.
- Shared folders and sync tools: Network shares and file sync clients that copy CUI to other machines pull those machines into the CUI scope.
- Backups: Backup systems that hold copies of CUI are CUI assets and must meet the media protection and encryption requirements.
Check whether a device ever touches CUI, even briefly, because the answer determines whether it is a CUI asset or a candidate for a narrower category.
Security protection assets do not hold CUI themselves but protect the CUI assets around them. Examples include firewalls, authentication servers, log collectors, endpoint protection consoles and the jump hosts used for administration. Under 32 CFR 170.19(c), these are assessed against the requirements that are relevant to their function, which is narrower than the full CUI set but still has to be shown to work.
- Boundary devices: Firewalls and VPN gateways are assessed against the boundary protection and remote access requirements.
- Identity services: Directory and multifactor services are assessed against the identification and authentication requirements.
- Logging and monitoring: Log collectors and SIEM components are assessed against the audit and accountability requirements.
- Endpoint tools: Antivirus and endpoint detection consoles are assessed against the malicious code protection requirements.
- Administrative paths: Jump hosts and privileged workstations are assessed against access control and maintenance requirements.
Confirm with your assessor which requirements apply to each protection asset in your environment, since the relevance depends on the design of your network and the functions each device performs.
Contractor risk managed assets are devices that can process, store or transmit CUI or that can affect CUI assets, but where the organization has chosen to manage risk through its system security plan rather than through a full assessment. In practice, this category captures ordinary business equipment that does not fit neatly elsewhere. The assessor expects to see the reasoning recorded, the risk accepted or mitigated and the owner of the decision named in the SSP.
- Documented reasoning: The SSP should state why each asset is in this category and what risk it presents.
- Compensating controls: Describe what limits exposure, such as network placement, restricted access or monitoring.
- Named owners: Each risk managed asset needs an accountable owner who reviews it on a schedule you set.
- Review triggers: Note the events that force a fresh look, such as a change in the device's network connection or its use.
- Consistency: Make sure the SSP matches what the network diagram shows, since mismatches are a common finding.
Ask your assessor how they expect risk managed assets to be recorded before you rely on this category for a device that holds CUI indirectly.
Specialized assets are the shop-floor devices that often cannot run the standard security tools used on office computers. The category names IoT, industrial IoT, operational technology and test equipment. Under 32 CFR 170.19(c), these assets are documented but not assessed. That does not remove them from the SSP. You still have to list them, describe how they connect and explain how the risk they carry is handled, and the assessor will check that description against the evidence.
- CNC controllers: Machine tool controllers are typically specialized assets, and the SSP should record their network connections and any file transfer method.
- IIoT sensors and gateways: Connected sensors and edge gateways must be inventoried, even if they are not assessed.
- Test equipment: Coordinate measuring machines, inspection stations and test rigs with embedded computers should be listed with their data paths.
- Enduring exceptions: Where full compliance is not feasible, document the mitigations and the reason in the SSP, as the rule provides for these exceptions.
- Inventory accuracy: An asset list that omits a connected machine is a more serious finding than an imperfect mitigation.
Verify whether each specialized asset ever stores CUI, such as program files or inspection data, because that fact can move it into a different category.
Assets that are physically or logically separated from CUI assets are out of scope under 32 CFR 170.19(c). This is the category most manufacturers want, and it is also the one most often misapplied. Separation must be real and provable, meaning the network path, the storage and the credentials are truly isolated, and the assessor can verify this from your diagrams and configuration. A shared Wi-Fi network or a shared file server does not qualify.
- Physical separation: Equipment on its own switches and cabling, with no route to the CUI enclave, is the clearest case.
- Logical separation: Segmentation with enforced deny-by-default rules between zones can separate assets, but the rules must be tested.
- Purpose-specific networks: For specialized assets, a separate network dedicated to that purpose is a common design option that keeps the OT out of the CUI boundary.
- Data transfer points: Any path that moves files between the two zones brings the device back into scope, so define and log those points carefully.
- Level 3 context: SI.L3-3.14.3e requires specialized assets to be included in the enhanced scope or segregated in purpose-specific networks. This applies only at the Level 3 boundary, so it is context for future planning rather than a Level 2 requirement.
Before relying on separation, have the assessor review your diagram and a sample of the rules that enforce it.
Enduring exceptions for CNC, test and legacy equipment
An enduring exception is the one route under the CMMC rule for equipment that cannot meet a Level 2 requirement in practice. Under 32 CFR 170.24(b) and the definitions in 32 CFR 170.4, an enduring exception covers situations where full compliance is not feasible, such as certain machines, test equipment, operational technology or Internet of Things devices. When the exception is documented with its mitigations in the system security plan, the assessor scores the affected requirement as MET. The key word is documented. An exception that exists only in someone's head, or in a shop supervisor's assumption that a CNC controller is "too old to patch," does not count, and it will not survive questions about what the machine can reach.
The exception is not a blanket excuse for the shop floor. For each piece of equipment, the system security plan should state why the requirement cannot be met, what compensating mitigations apply, who owns the decision and when it will be reviewed. Mitigations usually mean isolating the machine or controller on a purpose-specific network with no path to the enterprise network that stores drawings, and controlling who can load programs onto it. Evidence that supports the claim includes network diagrams and firewall rules showing the isolation, records of where CUI files are allowed to go, vendor statements that the controller cannot be patched or updated, and periodic reviews confirming nothing has drifted. Confirm with your assessor, before you rely on the approach, how they will accept vendor limitation statements and whether they expect a separate written justification for each asset.
Special circumstances and other security measures under DFARS 7012
This sequence shows how a manufacturer records the exceptions and temporary gaps that DFARS 252.204-7012(b)(3) allows, so each one is justified, mitigated in the system security plan and tracked until it closes. The result is a file an assessor can follow from the trigger to the closure record.
Inventory the systems that touch controlled technical information
Start from the drawings, specifications and process sheets you hold, then list every system that stores, processes or transmits them, including CAD workstations, PDM vaults, email and file shares. Record each one in the asset inventory with its owner. The output is an inventory that shows where the CUI sits, which gives every later determination a clear boundary. Confirm the definition of controlled technical information against DFARS 252.204-7012 with your contracts lead before you finalize the list.
Identify dynamic environments and special circumstances
Walk the production floor and the engineering areas to find conditions that make a standard control impractical, such as a medical device that cannot take patches, a fixture controller with a vendor-restricted operating system, or a shared test rig. The clause cites medical devices as an example of this kind of circumstance. The output is a documented determination for each condition that names the asset, the reason full compliance is not feasible and the person who made the call.
Document isolated, individual and temporary deficiencies
Separately record gaps that are not structural, such as one workstation missing a patch while a vendor fix is pending or one account that cannot use multifactor authentication until an upgrade. Give each deficiency a scope, a reason, a compensating measure and an expected end point. The output is a deficiency register entry for each item, kept apart from the enduring exceptions so that temporary gaps are never mistaken for permanent ones.
Decide whether a plan of action is needed
For each deficiency, decide whether it belongs in a plan of action and milestones under 32 CFR 170.21 or whether it is an enduring exception that the system security plan documents with mitigations under 32 CFR 170.24(b). Involve the Affirming Official in this decision because the score and the affirmation depend on it. The output is a recorded classification for each item, with the reasoning written next to it so an assessor can test it.
Address each measure in the system security plan
Write a dedicated section of the system security plan for each determination. It should describe the asset, the environment or circumstance, the mitigations in place (for example segmentation, restricted access, monitoring or manual controls), and who reviews the measure. Keep the language specific to your facility so an assessor can match it to what they see on the floor. The output is an approved revision of the SSP that references the register entries and the classification.
Verify mitigations with evidence
Test each stated mitigation the way an assessor would, using configuration exports, network diagrams, access lists, monitoring logs or signed procedures. Where a mitigation depends on a person, record the procedure and a sample of completed records. The output is an evidence package for each item in final form, not drafts, because the assessment method only accepts evidence that is complete. Ask your assessor early which evidence formats they accept.
Track each item to closure and review it
Set a review point for every temporary deficiency and every enduring exception, and assign an owner to each. When a patch lands, a system is replaced or a procedure changes, update the register, the SSP and the evidence together. Record the closure date and the evidence that shows the gap is gone. The output is a dated change history that shows the file stayed current between assessments, which is the record an assessor will ask to see.
Where NIST MEP centers help and where they stop
NIST's Manufacturing Extension Partnership gives manufacturers a practical starting point for cybersecurity risk work. The four cards below separate what an MEP Center can do for a shop from what only an independent assessor can issue, and show where its work hands off to a later implementation engagement.
Assessing cybersecurity risk posture
An MEP Center can help a manufacturer look at its current cybersecurity risk posture before any formal assessment is scheduled. For a shop that holds drawings and specifications, the useful output is a picture of where controlled technical information lives today: file shares, CAD vaults, email, engineering laptops and shared machine controllers. Ask the center to describe its method, who on its staff will do the work, and whether the findings are written for a contracts or engineering audience.
Identifying gaps against requirements
The second service is a gap view: which Level 2 practices are already in place, which are partial, and which are missing entirely. A manufacturer can use that list to decide what to fix first and what to document as a plan of action. Check that the gap list is traced to the NIST SP 800-171 requirements the contract actually flows down, and that it names specific systems and people rather than general themes.
Implementing solutions for contract requirements
MEP help can extend into implementation, such as setting up access controls, backups or logging on the systems a shop already runs. The purpose is to meet the legal and contractual cybersecurity requirements a customer has named. Before work starts, confirm in writing which systems are in scope, who owns the resulting configuration, and what documentation the shop keeps, since the system security plan must describe the system as it actually runs.
What MEP work cannot replace
An MEP Center does not issue certifications or attestations that a third party has independently checked a manufacturer's controls. A Level 2 certification assessment is performed by a C3PAO authorized or accredited by The Cyber AB, and a self-assessment is the organization's own determination, submitted through SPRS. Treat MEP outputs as preparation evidence and confirm with the customer or prime which assessment result they need before relying on any advisory report.
Who owns CMMC work in a manufacturing company
The manufacturer remains accountable for its CMMC program no matter who helps. Leadership decides which drawings, specifications and process sheets count as CUI, approves the system security plan, names the Affirming Official who signs affirmations, and decides how personnel are screened and trained. These are business decisions tied to contracts, so they cannot be delegated to a consultant or a vendor.
- CUI decisions: Marking and classifying technical information against the contracts and distribution statements that apply to it.
- SSP approval: Owning the system security plan, its scope statement and its description of how each requirement is met.
- Personnel: Screening staff with access to CUI, running role-based training and handling terminations and transfers.
- Affirmations: Confirming status in SPRS and signing affirmations through the Affirming Official, accurate at the time of signing.
- Operations: Running the controls day to day, including change approvals, access reviews and maintenance of shop-floor equipment.
Before engaging anyone, confirm internally who holds each of these roles and who will sign off on the scope boundary between the office network and the shop floor.
An implementation partner such as DeployOpen works inside the manufacturer's environment to prepare systems, configuration and evidence. Work is usually delivered under a fixed-scope agreement with deliverables and timelines written down before work starts. The partner does not decide what counts as CUI, does not approve the SSP on the company's behalf, and does not issue any assessment result.
- Systems: Hardening the directory, endpoints, network segments, logging and backup for the scoped CUI environment.
- Documentation: Drafting the system security plan, policies and procedures for the company to review and approve.
- Evidence: Setting up audit logs, access records, configuration baselines and POA&M tracking so that evidence exists in final form.
- Segmentation: Separating specialized assets such as test equipment or OT from CUI systems, or documenting them where they remain in scope.
- Support: Ongoing support, upgrades and retesting is available as a retainer after the assessment.
Ask for the written scope, the list of deliverables and the named owner for each control before signing.
Where a Level 2 certification assessment is required, a C3PAO authorized or accredited by The Cyber AB performs it. The assessor tests the environment against the assessment objectives of NIST SP 800-171A and decides whether each requirement is met. The assessor is independent of the manufacturer and of any implementation partner that helped prepare the environment, and the same firm cannot both build the controls and certify them.
- Independent testing: Reviewing evidence, interviewing staff and inspecting systems against assessment objectives.
- Scoring: Determining whether each requirement is MET, with evidence in final form rather than drafts.
- Certification: Issuing the certification result only through the accreditation body process.
- Scope review: Confirming that the assets the company placed out of scope really are separated from CUI.
- Limits: Assessors do not design controls or write the SSP for the company.
The status a company needs depends on the current implementation schedule in the Department of War's guidance, so confirm with the contracting officer which assessment applies to a given contract.
Manufacturers typically outsource the technical build and the evidence work, while keeping decisions and sign-off in house. Outside help is most useful for the parts that need specialized engineering time, such as identity, logging, segmentation and documentation. The contracts and the CUI classification remain the company's responsibility.
- Commonly outsourced: System hardening, identity and MFA setup, log collection, backup configuration and SSP drafting.
- Commonly kept in house: CUI marking, personnel screening, approval of the SSP and signing affirmations.
- Shared work: Training content, access reviews and the POA&M, where the partner drafts and the company owns the decisions.
- Pricing drivers: Number of CUI systems, shop-floor assets in scope, the state of existing systems and how much documentation is already written.
- Quote request: Ask for a fixed-scope statement that lists each deliverable, the responsible party and what is excluded.
Check that every outsourced task has a named owner inside the company who reviews the output before it becomes evidence.
The independence boundary separates the people who build controls from the people who assess them. A partner that helps prepare the environment can support the company through the process, but it cannot assess the same environment or issue the certification. Mixing these roles weakens the result and can disqualify the assessment. Keeping the roles distinct also makes the record easier to explain to a prime contractor or the government.
- Preparation is allowed: Partners can configure systems, draft documents and run mock reviews.
- Assessment is not: Partners cannot score the company's own controls or sign the certification result.
- Records: Keep a written log of who made each change so an assessor can trace evidence back to its owner.
- Contract language: Confirm in writing that the partner will not act as the assessor for the same scope.
- Requirements source: Check current assessment rules in the CMMC Program rule before finalizing roles.
Confirm with the assessor, before work starts, which activities they consider preparation and which they consider a conflict.
How to choose a partner for shop-floor compliance
A partner can prepare your shop-floor systems, drawings handling and evidence, but it cannot issue the assessment result. The cards below cover the checks that separate a useful implementation partner from a vendor that blurs the line between preparing for CMMC and passing it. Use them to shape your questions before any scope is agreed.
Experience with manufacturing and OT
Ask for examples of work on machine shops, CNC cells, inspection stations and plant networks, not only office IT. A partner should explain how it would handle controllers and PLCs that cannot run standard agents, and how it would separate them from CUI systems. Ask who on the team has worked on production floors and how they would document specialized assets for the assessment. Generic cloud experience alone does not answer these questions.
Understanding of CUI and drawings handling
The partner should be able to trace where drawings, specifications and process sheets travel, from CAD servers to email, file shares, supplier portals and printers. Ask how it would help you decide which technical information is controlled technical information and which is publicly releasable. A partner that cannot discuss distribution statements or your flowdown obligations is not ready to scope your environment.
Fixed-scope written deliverables
Before work starts, the scope, deliverables, responsibilities and timelines should be written down. Check that the document lists systems in scope, the controls the partner will configure, the evidence it will produce, and the items you keep. Vague hourly engagements make it hard to know what you paid for. Ask whether the partner charges separately for re-work after an assessor finds a gap.
Independence from the assessor
The organization that prepares your systems should not be the one that certifies them. Ask whether the partner or its staff are also an assessment body for the same engagement, and how it manages that conflict. Only an independent assessor issues the Level 2 result, so the partner's documentation is an input to that assessment, not its output.
Clear hand-off of evidence
Ask what you receive at the end: the system security plan, policies, configuration baselines, scan results, logs and any plan of action items, each in final form. Confirm who owns the documents, where they are stored, and how they are updated when your shop floor changes. Evidence that lives only in the partner's tools will be hard to maintain after the engagement ends.
Questions to ask before signing
Ask whether the partner can show a sample scope document, how it treats enduring exceptions and OT documentation, and what it would need from your engineering and quality teams. Ask who will do the hands-on work and whether they will remain on the account. Confirm that the partner does not issue reports or certificates. DeployOpen prepares systems, controls and evidence for compliance assessments, and independent assessors issue the results.
Common questions from manufacturers and machine shops
Does a shop that only holds drawings need CMMC Level 2?
Often yes, if those drawings are controlled technical information. Under DFARS 252.204-7012, technical information includes engineering drawings, associated lists, specifications and process sheets. Once that information carries controls on access, use or dissemination (distribution statements B through F under DoD Instruction 5230.24), it is controlled technical information and the systems that store, process or transmit it fall within the Level 2 requirements of NIST SP 800-171 Rev. 2. Information that is lawfully public without restrictions is excluded. Ask your prime or contracting officer which documents carry those markings, because the marking, not the shop's size, usually decides the question.
Can CNC machines and shop-floor equipment be excluded from CMMC scope?
Partly. Under 32 CFR 170.19(c), specialized assets such as IoT, operational technology and test equipment are documented in the system security plan but are not assessed, while assets physically or logically separated from CUI assets are out of scope. A CNC controller that only runs toolpaths and never touches the CUI network can therefore fall outside the assessed boundary. The separation must be real: a shared file share, a networked DNC server or a laptop that moves drawings between the two sides brings the machine back into scope. Map every networked machine, document its role and confirm the segregation with a network diagram before deciding.
What is an enduring exception, and how do I document one?
An enduring exception is a specialized asset, such as a piece of test equipment, OT or an IoT device, where full compliance with the Level 2 requirements is not feasible. Under 32 CFR 170.24(b) and 170.4, an enduring exception that is documented with mitigations in the system security plan is assessed as MET. The documentation has to name the asset, explain why the requirement cannot be met, describe the compensating mitigations (for example, network isolation or restricted access) and show how the asset is monitored. Vague statements such as "legacy equipment" will not satisfy an assessor. Expect the assessor to test whether the mitigations actually exist.
Does the Phase II suspension remove our CMMC obligation?
No. On 13 July 2026 the Department of War suspended CMMC Phase II, which had covered Level 2 certification by a C3PAO for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. The suspension does not touch the rest of the framework. Phase I self-assessments, SPRS postings, annual affirmations and the DFARS 252.204-7012 obligations remain in place. The Department also said it will enforce NIST SP 800-171 Rev. 2 in the interim. A shop that handles CUI already has safeguarding and incident reporting duties, so the suspension changes when a third-party certification may be required, not whether the controls must work. Confirm the current status on the DoW CIO site before you set your plan.
How much of the Level 2 work must our own staff do?
The organization owns its controls, so its people must operate them, even when a partner builds the systems. Expect internal ownership of the decisions and daily operation: approving access, reviewing logs, running change control on machine software, sanitizing media, and signing off on the system security plan. An implementation partner can prepare the environment, configure the controls and draft the documentation, but a Level 2 self-assessment must reflect what your staff actually do. Ask any outside provider to state in writing which tasks it performs, which tasks your team performs, and which evidence each side will produce. Only an independent assessor can issue the certification outcome.
Can a NIST MEP center help us before we engage a consultant?
Yes. NIST's Manufacturing Extension Partnership says manufacturers can contact an MEP Center for help assessing their cybersecurity risk posture, identifying gaps and implementing solutions to meet legal and contractual cybersecurity requirements. That makes an MEP Center a sensible first conversation for a shop that does not yet know which documents are controlled or where its gaps sit. Use the conversation to produce a list of data flows, machines and drawing repositories, then decide what to buy. Check the MEP program's current services and eligibility directly with your local center, since offerings vary by region and may change.
How DeployOpen prepares a shop for its assessment
DeployOpen works on CMMC for manufacturers and machine shops by preparing the systems, controls and evidence that hold controlled technical information, inside your own infrastructure. We do not issue assessment results; the organization owns its controls and an independent assessor makes the determination.
How we scope
- We map where drawings, specifications and process sheets are stored, shared and printed across engineering and the shop floor.
- We separate CUI assets from OT, test equipment and other specialized assets so the boundary matches what the written scope covers.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- We implement and harden self-hosted open-source platforms for access control, logging, configuration baselines and backups in your environment.
- We document enduring exceptions and segmentation for shop-floor equipment in the system security plan, with mitigations stated.
- We test the configured controls against the NIST SP 800-171A objectives so gaps surface before an assessor arrives.
How we hand over
- We deliver the system security plan, control narratives, network diagrams and asset inventory in final, reviewable form.
- We produce evidence packages such as configuration exports, access reviews and log samples, with a note on where each item is kept.
- We walk your staff through the plan of action and milestones so your team can run the controls after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement closes.
- We help you keep evidence current between assessments, including periodic reviews of scope as shop equipment and drawing workflows change.
- Ask us to confirm which parts of the work your own staff, your IT provider or an assessment body would perform before you request a quote.
