The Gap Between the Gap Assessment and the Controls

The gap assessment closes on a Thursday. Twenty-six findings, organized by control domain — access management, monitoring, vendor risk, incident response. Your client is a defense contractor with a CMMC Level 2 assessment window tied to a contract award that came through in Q1. The remediation clock started then. The C3PAO assessment is 14 months out.

The report is solid. The client's COO thanks you for the clarity. The document goes into a shared drive.

Three months later, four findings have closed. The remaining twenty-two are tracked in a spreadsheet with status columns that haven't moved. The controls that haven't advanced are the ones that require dedicated engineering time: RBAC configuration across three environments, audit log pipelines for continuous monitoring, vendor risk assessments for eight SaaS tools in the stack, an IR plan with a documented tabletop on record. Your calendar is carrying three other engagements. The hours that would close those findings are the hours going toward your other clients' advisory work.

This is the gap assessment stall. It appears across frameworks — CMMC Level 2, SOC 2 Type II, ISO 27001 — whenever the advisory and engineering work land in the same calendar. The assessment produces a findings list. Neither the report nor the framework delivers what closes it.

The Assessment Ends Where the Engineering Begins

A gap assessment produces a findings list structured by control domain. Across frameworks, the findings look similar: access controls not configured, monitoring evidence missing, vendor risk not documented, MFA not enforced. Each finding names the gap accurately. None of them close themselves.

The engineering work that follows includes what the report doesn't:

• RBAC configuration, access policy documentation, provisioning runbooks — the engineering implementation that makes a CC6.1 or AC.L2-3.1.1 finding closeable with an audit artifact behind it
• Vulnerability scanner output wired into a continuous evidence pipeline — the artifact generated, timestamped, and retained on a schedule that covers the full audit period
• Vendor risk register built and populated, third-party assessments documented for CC9.2 — the engineering that puts evidence behind the finding
• MFA enforced and logged, access review processes built with a documented cadence, IR policies written and exercised — controls producing audit artifacts on an operating schedule

For the vCISO who does their own engineering, this is familiar work. The question in a hard-deadline engagement isn't whether they can do it — it's how many clients they can carry while doing it.

The Work That Runs Every Quarter

The vCISO who does their own engineering knows exactly what the execution layer looks like. Quarterly access review cycles — pulling the user list, documenting who reviewed what, logging the outcome. Evidence collection runs — exporting configuration state, pulling scan results, submitting artifacts. Vendor risk register updates each time a new SaaS tool enters the client's stack. These aren't hard problems. They're time problems.

The reason these tasks land on the vCISO isn't because they require advisory judgment — it's because they require someone who understands the control framework well enough to execute it correctly, and that person is usually already carrying the strategic work.

FEDLIN takes that execution layer off the advisory engagement. The access reviews run on a defined cadence and produce a stored record. The evidence pipeline collects automatically. When a new vendor enters the client's stack, the vendor assessment gets built. The vCISO's hours go toward the work that requires their specific expertise — the advisory work clients are paying for — while the execution runs in parallel under a dedicated engineering owner.

For an engagement with 20–40 findings, each with a maintenance cycle behind it, the execution layer is significant volume — and it has to be running before the audit period opens, not assembled in the weeks before the audit call.

A Platform and an Engineer in the Same Engagement

The GRC platform question tends to surface early in any compliance engagement — often before the controls it would track have been built.

FEDLIN handles the GRC layer: a compliance platform configured to the specific requirements of the engagement — CMMC Level 2 practices, SOC 2 Trust Service Criteria, ISO 27001 controls, or a combined scope mapped directly from the gap assessment findings — alongside the engineering that sets it up and keeps it running. Evidence submits automatically. Remediation tracks against the findings list. The vCISO has full visibility without managing the tooling.

The combination — a platform purpose-configured for the engagement, plus an engineer who can extend the configuration as scope evolves — is what makes the GRC layer serve the advisory work.

What the Advisory/Engineering Split Returns

The vCISO who separates the advisory work from the engineering execution can take on more client engagements in the same compliance cycle. The strategic work — scoping the control boundary, sequencing remediation, managing the audit relationship — is where fractional advisory expertise commands its highest value. The engineering execution — deploying the controls, wiring the evidence pipelines, building the artifacts — is where FEDLIN operates.

Remediation velocity. The findings list moves because there's a dedicated engineering owner on each item — not because it fits into the advisor's available hours alongside client calls and risk updates. Findings that require dedicated sprint capacity (IR policy builds, access review process design, vendor risk register population) have an engineering owner from the moment the assessment closes.

Evidence pipelines running at period start. For SOC 2 Type II, the evidence pipeline has to be generating artifacts before the audit period begins. For CMMC Level 2, controls need to be in place before the C3PAO arrives. For ISO 27001, continuous monitoring evidence has to cover the certification period. In each case, the engineering work starts at the assessment handoff — the window doesn't wait.

Advisory depth across more engagements. The vCISO who carries the engineering work limits their advisory capacity to what a single person's hours support. The split makes both layers scale independently — which is what the current volume of compliance demand across frameworks actually requires.

The Enforcement Cycle Is the Opportunity

CMMC Level 2 gets the headlines. CMMC Level 1 is where most of the defense industrial base actually operates.

The 17 basic cyber hygiene practices under FAR 52.204-21 apply to any DoD contractor handling Federal Contract Information. Self-attestation is still permitted at Level 1 — but the attestation has to be accurate and maintained across the contract period. For the small and mid-size businesses that hold active federal contracts in this tier, that condition is the basis for contract continuation, not an abstract compliance checkbox.

The fractional vCISO advising these clients is already positioned to serve that work — they understand the framework, can scope the control boundary, and know what accurate attestation requires. The constraint is implementation hours: a client who needs 17 practices deployed and maintained, with evidence cycles running between attestation windows, requires engineering time that doesn't fit cleanly inside an advisory retainer.

The advisory/engineering split is what makes the engagement scale. The vCISO handles the scoping, the attestation review, the client relationship. FEDLIN carries the implementation — building the controls, maintaining the evidence cadence, keeping the controls deployed and evidence running between attestation windows. That structure serves the client. It also means the vCISO's capacity isn't consumed by one client's engineering backlog when there are several more contracts in the pipeline that need the same work done.