A supplier remediation plan is useful only if it changes the decision to use the service and tells someone how to verify that the gap has closed. “Vendor will improve logging next quarter” leaves the customer with an unresolved exposure, no interim protection and no testable endpoint. This guide provides an onboarding condition tracker that connects each material gap to the affected service, temporary safeguard, accountable owner, deadline, independent closure check and release decision. It is designed for a buyer deciding whether and when a new service may start, rather than for a general supplier scorecard.
The broader NIS2 risk management overview explains the directive’s supply-chain category. NIST SP 1305 describes using the Cybersecurity Framework to define and communicate supplier requirements, while NIST SP 800-53A Rev. 5 provides adaptable methods for assessing controls. Neither source makes every buyer subject to the same onboarding deadline or requires a particular software tool. Applicable legal and contractual duties depend on the entity, service, data and jurisdiction; the tracker is a practical way to make a local decision explainable.
State the service decision before reviewing the plan
Describe what the supplier will provide and which business process depends on it. Include the customer population, data categories, privileged access, integrations and planned start date. A gap may be tolerable for a synthetic-data pilot but unacceptable for production access to customer records. Without the intended use, reviewers may accept a remediation promise for a service wider than the one they assessed. Record both the proposed use and any limits that would be technically or contractually enforceable.
Decide who can accept which condition. Procurement can coordinate the contract, the technical owner can inspect an implementation, privacy staff can assess personal-data implications and the business owner can explain operational impact. None of those roles automatically has authority to waive a mandatory requirement. The decision record should name the final approver and the evidence they relied on. The security-control ownership guide for acquisitions helps separate controls that the supplier runs from configurations the buyer must operate.
Classify the issue before it becomes a task. Is it a missing control, insufficient evidence for an existing control, a contractual ambiguity or an incompatibility with the proposed use? A missing SOC report is not the same as an untested backup; a contract promise is not proof of a running process. The tracker should preserve that distinction, because the closure method differs. Asking for another PDF will not close a failed restore test, and repeating a technical test will not resolve a missing right to terminate.
Build the condition tracker around decisions
A useful row has enough detail to stand alone after the procurement meeting. Give it a stable identifier and link the exact supplier response or test result that raised it. Record the business consequence, not just a framework label. Then write a closure criterion in observable terms. “Implement MFA” may be too vague: which accounts, which environment, how will exceptions be handled and what evidence shows enforcement? A reviewer should be able to judge the result without renegotiating the meaning of the requirement.
| Field | Question the row must answer |
|---|---|
| Gap and scope | What is missing, for which service, accounts or data? |
| Exposure | What could happen before the gap is closed? |
| Interim protection | What actually limits the exposure during onboarding? |
| Owner and deadline | Who acts, who supplies proof and when is it due? |
| Closure criterion | What observation would establish that the requirement is met? |
| Reviewer and result | Who checked the evidence, by what method and with what limit? |
| Service decision | Start, limited start, defer or reject, under which conditions? |
Keep the original finding when the supplier revises the plan. Replace neither a missed deadline nor a failed test with a new optimistic status. Add a dated update that explains the change and its effect on service use. If several issues interact, mark the dependency: a planned monitoring control may rely on an integration that has not been deployed. Closing the monitoring row before that integration works would create a false green result. A simple spreadsheet can support this structure if ownership, access and history are reliable.
Make interim protection real
An interim safeguard must be in place before the exposure begins. A supplier might limit access to a small named team, use synthetic records, disable a feature or route a process through a monitored manual step. Confirm that the customer can enforce or observe the limit. “Use only non-sensitive data” is weak if the application accepts arbitrary files and staff have not been instructed or restricted. Document the configuration, operator and check that keep the boundary intact.
Temporary controls have costs and failure modes. A manual approval may slow operations and fail during absence. A compensating log review may not detect the event quickly enough to prevent harm. State what risk remains and how long the condition is acceptable. The GDPR Article 32 security guide addresses protection of personal-data processing, but an internal acceptance of residual risk cannot make an otherwise unlawful processing arrangement lawful. Confirm the legal basis and processor terms separately where they apply.
If no workable interim protection exists, defer the activity that creates the exposure. A signed action plan is not itself a safeguard. The buyer may still complete contract negotiations, configure a non-production tenant or test with artificial data. The tracker should show precisely which activities are authorised. Avoid language such as “supplier approved pending all actions” when the approval actually concerns only a restricted trial.
Set deadlines that reflect the service dependency
The supplier’s target date should match the buyer’s go-live gate. If a material gap must close before production, write “before production access” as the condition and add a planning date for scheduling. An arbitrary calendar deadline after launch does not protect the service during the intervening period. For a lower-priority issue that can remain open, identify the review date and the reason for accepting the period. Do not borrow a fixed remediation interval from a framework and present it as a universal legal rule.
Define escalation before a deadline is missed. Who is notified, who can extend it, and what happens to access or data flow? If the supplier repeatedly postpones a fix, the buyer needs a decision about continued use, not another silent date change. Record both the supplier’s explanation and the customer’s assessment. A missed deadline may increase risk even when the underlying technical gap has not changed, because confidence in execution has weakened.
Make closure criteria independent of the supplier’s project status. “Development complete” is a delivery milestone, while “the intended control operates in the contracted tenant under the buyer’s conditions” is a testable outcome. If the fix requires a platform release, record the version and deployment date that reach the buyer’s environment. A feature announcement for another region or plan is not evidence that the purchased service now has the capability.
Choose evidence that answers the gap
Use the least intrusive method that can support the decision. A policy, design note or contract clause may answer a governance question. A configuration export, live demonstration or controlled test may be needed for a technical behaviour. A report from an independent assessor can help if its scope, period and tested service match the issue. NIST SP 800-53A frames assessment around examining material, interviewing people and testing mechanisms; the specific combination is chosen for the control and assurance needed.
Ask the supplier to identify evidence precisely. A screen capture should include enough context to establish tenant, date, configuration and relevant account without exposing secrets. An assurance report should state the organisation, covered service, period, exclusions and complementary customer controls. A generic certificate logo does not show that the remediation was implemented in the service you will use. Where a test cannot be performed safely, document the alternative evidence and the remaining uncertainty rather than claiming equivalent assurance without reason.
The buyer’s reviewer should be able to reproduce the conclusion. Record what was inspected, the expected result, observed result and any assistance provided by the supplier. If the supplier led the demonstration, note which parts the buyer could independently see. The GDPR audit methodology illustrates how to connect a finding with evidence and a correction; a supplier check should be equally explicit about its limited scope.
Treat partial closure as a new decision
A fix may cover only some users or environments. If MFA now protects administrators but not support contractors, the original issue is not fully closed. It may be split into a completed part and a remaining condition, with both traceable to the first finding. Similarly, a backup test that restores files but not the usable service demonstrates only part of the objective. Describe the limitation in plain language so the business owner understands what risk remains.
A supplier may offer a contractual assurance while technical evidence is pending. That promise can support accountability or a remedy if breached, but it does not demonstrate current operation. Decide whether the contract and interim safeguards permit limited use, or whether production must wait. For financial entities in scope, DORA third-party risk management adds specific ICT provider requirements; it should not be applied as a blanket duty to every SaaS purchase.
When the buyer changes the intended use, reassess the condition. A limited pilot that excluded personal data may become a production service with customer records. The earlier acceptance cannot silently expand with it. Update the exposure, interim protection and closure test, then issue a new decision. This is why the tracker links the gap to a defined service scenario instead of to the supplier’s name alone.
A worked onboarding case
A company plans to use a hosted document service. The supplier says that administrative activity is logged, but cannot show that customer administrators can retrieve an activity trail for the contracted tenant. The buyer’s concern is reconstruction of changes to access settings after a suspected account compromise. The row records the missing tenant-specific evidence, the production population affected and a proposed closure test: perform a controlled role change, retrieve the event with actor, timestamp and target, and confirm it is available to the agreed response team.
The supplier proposes a fix in its next release. The buyer allows a restricted pilot with synthetic documents and a small named user group, provided the customer can enforce these limits. Procurement records that production use and external sharing remain blocked. The technical owner checks the pilot configuration weekly and reports any drift. This is an interim protection with an owner and observation, not merely an assertion that the team intends to be careful.
At the target date, a demonstration shows that an event appears in the supplier’s administrator console, but it cannot yet be exported or made available to the customer response team. The reviewer records partial progress and retains the production block. A later release provides the agreed access; the reviewer repeats the role-change test in the contracted tenant, preserves the result and signs the closure row. The business owner then approves the broader launch. The original failed attempt stays in the record, showing how the decision changed as evidence improved.
Decide what to do when closure fails
A failed closure check should trigger a decision, not just another evidence request. Consider whether the service can be used in a narrower mode, whether an independently verified compensating control is available, whether a different supplier is needed, or whether the business process must wait. Include exit and data-retrieval consequences if the supplier has already received information. The DORA ICT risk management guide places such dependencies in a wider resilience framework for covered financial entities; other buyers can use the operational question without adopting DORA’s legal scope.
Keep the decision separate from the supplier’s own assurance. A supplier can attest that it fixed the issue; the customer decides whether the evidence meets the agreed criterion. Independence can mean review by a person other than the implementer, an external report or a controlled buyer test, depending on risk. It need not mean a full external audit for every minor finding. Record the review method and any limitation so the claimed independence is proportionate and honest.
If accepting a remaining risk is permitted, name who can do so and for how long. State the factual gap, foreseeable consequence, restrictions and revisit trigger. Do not phrase acceptance as proof of compliance. Some contractual or regulatory requirements cannot be waived by an internal vote. Where personal data are processed, assess the controller and processor arrangement, security and transfers on their own terms; a remediation spreadsheet cannot replace those decisions.
Keep the plan alive after go-live
A closed condition can reopen when the service changes. A new region, subcontractor, identity system or logging architecture may invalidate the earlier test. Connect the row to change notifications and periodic supplier review. Preserve the configuration or report version used at acceptance so later reviewers can see what has changed. The third-party OAuth consent review shows a related pattern: approved access can outlive the original business purpose unless someone checks continued use and ownership.
Report the state of material conditions to the service owner in terms they can act on: which activities are allowed, which remain blocked, what evidence is due and who will decide. A count of “open supplier actions” is less informative than a short account of the unresolved exposure. Track time to verified closure, but do not reward closure speed by accepting weak proof. The tracker succeeds when a person arriving after the procurement meeting can reconstruct why the service was allowed to start, what protection existed before each gap closed and what observation finally justified the decision.