Time-box a supplier security exception before onboarding

The supplier can start on Monday. One security requirement cannot be met until next month. The business asks whether a restricted launch can proceed.

Before answering, define what would happen if the promised fix never arrives. An expiry date is useful only when someone can enforce the restrictions, assess the evidence and stop or change the service when approval ends.

This guide offers a practical exception record for that temporary period. It complements the broader supplier decision record, rather than replacing the assessment behind it.

Establish whether an exception is available

Identify the exact unmet requirement and where it comes from: internal policy, contract, law or a regulatory obligation. Check who has authority to approve the proposed departure. A project sponsor's urgency does not establish that authority. A contractual departure may also need counterparty consent under the agreement; an internal approval does not supply that consent.

An internal exception cannot waive legislation or a prudential requirement. For APRA-regulated entities, CPS 234 requires appropriate information security controls, assessment of relevant third-party capability and notification of material control weaknesses meeting its criteria. Internal acceptance does not remove those obligations. Obtain specialist advice where applicability or permissible options are unclear.

NIST CSF 2.0, ID.RA-07 provides a useful governance outcome: assess the risk effect of exceptions and keep them recorded and tracked. It does not prescribe a universal exception period or authorise a particular supplier to go live.

Describe the exposure during the exception

Record the service, information, users and connections the temporary approval would cover. Distinguish a known missing control from uncertainty about whether a control operates. Both need assessment, but they are different problems.

Explain what could happen during the proposed window and why the interim arrangements are proportionate. Keep future improvements outside the current control assessment. The inherent and residual risk guide covers that distinction in detail.

Compare a restricted launch with waiting, changing scope or using an existing process. If the organisation cannot safely operate within the proposed limits, an exception form will not make the proposal viable.

Put the temporary protections in place first

Every restriction needs an operator and a way to check it. “Enhanced monitoring” should specify who examines which events, how often they do it and what they do when something is wrong.

Check the interim controls before enabling the permitted activity. A supplier's planned change cannot compensate for today's gap. Equally, a buyer-side manual review is unreliable if nobody has time or access to perform it.

NIST SP 800-39, Appendix H describes risk-response implementation strategies that include accountable parties, dependencies, timelines, monitoring triggers and interim measures. The record below adapts that thinking to onboarding; it is not a NIST-mandated template.

Worked example: a restricted forecasting pilot

Banksia Distribution is a fictional Australian wholesaler evaluating a forecasting service. Its internal standard requires administrative audit events to reach its central monitoring service before live use. The supplier's tenant-specific integration is delayed.

The proposed pilot uses product-level sales totals. Customer records and order-level details are excluded. Six named staff will compare forecasts with the existing planning process, which remains authoritative. The service cannot place orders or write to operational systems.

Security has verified enforced multifactor authentication, the permitted user list and the audit events available through the supplier's console. An internal analyst can export and review those events each business day. This leaves a longer detection delay than the required integration, including weekends. The exception assessment states that limitation and the exposure of commercially sensitive forecasts.

Under Banksia's fictional delegation, the operations director can decide this bounded internal-policy exception after security review. The director approves the pilot only after the restrictions and fallback are checked. This authority is invented for the example, not a recommended delegation for every organisation.

The exception record reads:

• Scope: six named users, approved product-level dataset and comparison-only forecasting pilot.
• Gap: administrative audit events are not yet delivered to central monitoring. Link the policy clause, finding and assessment.
• Decision owner: operations director, with the applicable delegation recorded. Security reviewer assesses the control evidence; the service owner coordinates delivery.
• Effective period: 26 October 2026 to 13 November 2026 at 5 pm Brisbane time. No automatic extension.
• Interim duties: the security analyst, or a named deputy, retains and reviews the previous period's audit events by noon each business day, including weekend events in Monday's review. The service owner checks the user list and dataset restrictions weekly.
• Closure evidence: a witnessed tenant test showing required events reach central monitoring with usable timestamps and actor details, plus a demonstrated alert-routing test. Security records the result and any exclusions.
• Checkpoint: integration evidence due by 9 November, leaving time for testing and a decision before expiry.
• Immediate stop triggers: audit export becomes unavailable, the agreed review is missed or unauthorised data or access is identified. Follow the incident process where relevant.
• Reapproval triggers: additional users, expanded data, a new connection or changed use of forecasts. Do not implement the change under the existing exception.
• Expiry action: without an authorised continuation decision based on verified closure or fresh exception approval, the service owner stops uploads and suspends pilot access. Planning continues through the existing process. Evidence and data are handled under the agreed retention arrangements.

Decide the ending before the deadline

Keep the evidence checkpoint separate from the expiry. A checkpoint creates time to assess progress; expiry ends the authority granted by this record. Choose the interval around the exposure, validation work and ability to stop safely, not a default 30 or 90 days.

If the integration passes review, record security's validation and the authorised decision on whether the pilot may continue under normal approval arrangements. The remediation closure guide explains how to judge the evidence. Closing this exception does not approve a wider rollout.

If the work slips, preserve the original record. Any extension needs an updated assessment, a reason the revised plan is credible and a fresh decision within delegated authority. Repeated extensions should prompt reconsideration of scope or supplier choice.

Before launch, ask the person responsible for expiry to explain what they will do if nobody responds. If the answer is simply “send another reminder”, the temporary approval is not yet ready to operate.