Vendor & Subcontractor Management Plan — BenefitConnect Task Order

This plan defines how Acme Federal Systems manages the external parties its BenefitConnect Task Order depends on. It is deliberately not a subcontractor-staffing plan: this Task Order is performed by an all-onshore, all-U.S.-persons team, so there is no offshore or subcontracted delivery labor to govern. What there is — and what a Firm-Fixed-Price federal task order genuinely depends on — is a set of external relationships the contractor does not control but is accountable for: the incumbent legacy vendor being sunset, whose cooperation the migration needs; the Government-furnished access the work cannot start without; an independent Government auditor inserted into the deliverable process; and the mandatory contract clauses that must flow down to anyone who touches applicant data. This plan governs those, because on an FFP task order an external party's failure becomes the contractor's cost.

FFP

External risk is contractor risk

External relationship types governed

100%

Onshore / U.S. persons (flows down)

GFP

Work gated on Government-furnished access

01 Why this plan is not a subcontractor-staffing plan

Most commercial vendor-management plans are about labor: which firms supply which people at what rate. This one is not, and saying so plainly is the first act of understanding the contract. The BenefitConnect Task Order requires that all delivery-team personnel handling applicant PII be U.S. persons performing work onshore (PWS 6.1 / 7.1 / 10.4 (US-persons, onshore)), with no offshore staffing permitted. Acme Federal Systems staffs the effort directly against that constraint; there is no subcontracted or offshore delivery tier to manage, and inventing one would misrepresent the program.

But an FFP federal task order still runs on external parties the contractor is accountable for without controlling. A Firm-Fixed-Price structure (PWS 6.2 (Firm-Fixed-Price)) means the contractor absorbs the cost of any schedule slip or rework — including slips caused by a vendor who is not on the contractor's payroll. That is what makes external-party management a real discipline here rather than a procurement footnote: when a dependency fails, the price does not change, so the contractor manages the dependency as if it were its own.

The governing question of this plan: for each external party the Task Order depends on, what is the contractor's mechanism to manage a dependency it does not own? The four sections that follow answer that for the four relationship types — the legacy vendor, Government-furnished property, the independent auditor, and clause flowdown — and each terminates the same way: in a named owner and a tracked dependency, not an assumption.

02 The legacy vendor transition — a dependency, not a subcontract

The largest external relationship on this Task Order is with the incumbent legacy vendor whose benefits platform BenefitConnect replaces. That vendor is not Acme Federal Systems's subcontractor — it is a third party whose product is being retired, and whose cooperation the migration nonetheless requires. The business case for the entire Task Order rests on the fact that the legacy vendor's support is approaching end-of-life, so continuing it is not a viable long-term option; that same end-of-life is what makes the transition delicate.

Transition dependency	How it is managed
Data extraction & format cooperation	Migration depends on obtaining a clean, well-structured export from the legacy system. This is managed as a scheduled dependency with the migration lead, not assumed — a mod in the change log records that the legacy vendor provided a better-structured export than planned, which reduced tooling spend. Cooperation is tracked because it cannot be compelled.
Legacy read-access continuity	Read access to the legacy portal must remain available through validation, not just extraction — managed through the GFP dependency in §03, since the access is Government-furnished rather than vendor-granted.
Vendor sunset timing	The legacy vendor's end-of-support timeline is the forcing function for the Task Order; the transition is sequenced so that BenefitConnect is accepted before legacy support lapses, with the sunset treated as a fixed external date the contractor plans backwards from.

The legacy vendor is managed as a risk, because it is one. The contractor has no contractual authority over a vendor whose product it is replacing, and that vendor has limited incentive to expedite its own retirement. Naming this relationship, sequencing around its end-of-life, and tracking its cooperation as a dependency rather than a certainty is the honest way to manage a party you depend on but cannot direct.

03 Government-furnished property — the dependency that gates the work

The most consequential external dependency on this Task Order is not a vendor at all: it is the Government itself. Under PWS 8.1 (Legacy System Read Access), FOPBA provides Acme Federal Systems read access to the legacy benefits portal database and application-server logs for migration planning and validation. This is Government-Furnished Property, and it is a dependency in the strict sense — the contractor cannot begin the work it enables until the Government provides it, and cannot be faulted for a delay the Government causes.

GFP inverts the usual accountability. For every other party in this plan, Acme Federal Systems is the one accountable for performance. For GFP, the obligation runs the other way: FOPBA must furnish the access, and until it does, the dependent contractor work cannot proceed. This is why the Task Order's own traceability terminates GFP requirements in a dependency, not a contractor verification — the contractor's duty is to be ready to use the property and to document any delay in receiving it, not to produce it. This plan manages GFP by tracking its provision as a gating dependency with the Government as owner, so that a late furnishing is visible as a Government-caused impact rather than a contractor slip absorbed silently under the fixed price.

04 The independent Section 508 auditor — an external party in the deliverable chain

Contract modification P00001 added an independent Section 508 auditor to the CDRL review process — a COR-directed insertion of an independent Government auditor into the review of the accessibility test deliverables (A004/A006). This is a distinctive external relationship: the auditor is neither Acme Federal Systems's subcontractor nor a vendor, but an independent reviewer in the acceptance path, whose judgment the contractor's deliverable must satisfy.

Coordination obligation	Why it matters
Deliverable readiness for independent review	The accessibility deliverables must be complete and defensible for an independent auditor, not merely self-attested — the mod exists precisely to replace contractor self-attestation with independent verification.
Schedule coordination with an external reviewer	The auditor's availability is outside Acme Federal Systems's control and becomes a scheduling dependency in the acceptance path; a review slot that slips can move a CDRL acceptance, so it is coordinated as an external dependency rather than assumed on demand.
Findings resolution loop	Independent findings must be resolved and re-reviewed; the contractor manages the loop to closure, since under FFP the cost of rework to satisfy the auditor is the contractor's.

An independent auditor is a stricter gate than self-certification — on purpose. The value of the mod is exactly that the contractor cannot mark its own homework on accessibility. Managing this relationship means treating the auditor's independence as a feature to be satisfied, not an obstacle to be negotiated, and carrying the auditor's availability as a real dependency in the acceptance schedule.

05 Clause flow-down — what any external party touching the data is held to

Where Acme Federal Systems does engage any external party in a way that touches applicant data or the delivered system, a defined set of mandatory requirements flows down — the same requirements the Task Order imposes on Acme Federal Systems. These are not optional terms; they are conditions of federal performance, and flowing them down is how the contractor keeps its own compliance intact through anyone it involves.

Flowed-down requirement	Source & why it cannot be waived
U.S. persons, onshore performance	PWS 6.1 / 7.1 / 10.4 (US-persons, onshore): anyone handling applicant PII must be a U.S. person working onshore, with no offshore performance — a data-sovereignty and privacy requirement, not a cost preference. It flows down intact because the constraint is on the data, not on who employs the person.
Security & ATO obligations	The system must pass a Security Control Assessment and obtain its authorization; any party contributing to it inherits the security controls and evidence obligations, because an ATO cannot be granted on a component nobody attested.
Firm-Fixed-Price risk posture	PWS 6.2 (Firm-Fixed-Price): because rework and overrun are the contractor's cost, any external engagement is structured so that performance risk sits with the party that controls the work — the contractor does not accept fixed-price accountability for scope it cannot direct.
Record retention & auditability	Federal acceptance rests on records; any external party's work must be documented to the same standard, so that the contractor can evidence compliance at COR inspection for the whole of what it delivers, including what others contributed.

Flow-down is how the contractor stays compliant through others. Acme Federal Systems is accountable to the COR for every requirement of the Task Order regardless of who performs the underlying work. Flowing the mandatory clauses down — onshore, security, FFP risk posture, record retention — is the mechanism that keeps that accountability whole: the contractor never inherits a compliance gap from an external party because the party was held to the same bar before it was engaged.

06 External-dependency register

The four relationship types consolidate into a single register — the management instrument that makes this plan operational rather than descriptive. Each external dependency has a named owner and is tracked as a live item, because the Firm-Fixed-Price structure means an untracked external dependency is an unpriced risk the contractor will absorb.

External party	Relationship	Dependency tracked	Owner
Incumbent legacy vendor	Third party being sunset	Data export cooperation; read-access continuity through validation; sunset timing vs. acceptance	Migration Lead
FOPBA (as GFP provider)	Government furnisher	Provision of legacy read access (PWS 8.1) — gates dependent work; late furnishing is a Government-caused impact	COR / PM
Independent 508 auditor	Reviewer in acceptance path	Availability for CDRL A004/A006 review; findings-resolution loop to closure	Quality / Compliance Lead
Any data-touching engagement	Flow-down recipient	Onshore/US-persons, security/ATO, FFP risk posture, record retention held before engagement	Contracts / PM

The register is the plan's teeth. A vendor-management plan that names relationships but does not track them is a description, not a control. Every row here resolves to an owner who is accountable for a specific external dependency and to a status that is reviewed, so that a legacy vendor going quiet, a Government furnishing running late, or an auditor slot slipping is seen as it happens — while there is still time to manage the impact rather than absorb it after the fact under a fixed price.

07 How this plan sits in the suite

This plan is the external-dependency counterpart to the suite's internal management artifacts. It draws the legacy-vendor framing from the TCO and CBA, the GFP dependency and the onshore/FFP constraints from the PWS, and the independent-auditor relationship from contract modification P00001. It complements the Requirements Traceability Matrix, which traces what the contractor must deliver, by governing the external parties the delivery depends on. Together they express the same federal reality from two sides: on a Firm-Fixed-Price task order, the contractor is accountable not only for its own work but for every external dependency that work rests on — so each one is named, owned, and tracked rather than assumed.