Architecture Portal

Protecting the cancellation case

A partner handover with limited authority.

Adrian Sutherland · Version 1.0 · · © 2005–2026

The proposed extension

The training-provider example begins with a process-only trial and later considers a case service. This security extension is fictional and unimplemented. It preserves the existing acceptance contract: the named receiver accepts handover H7 (Example transfer offer) for case C42 (Example cancellation case) at version 12. Operation X7 (Acceptance operation) records the accepted change and receipt together, moving the case to version 13. Notification follows that accepted result.

Risks and controls

Record Harm and proposed control Owner and check
SEC-R1 (Excess disclosure) A partner sees unrelated learner information. Limit disclosure to the case and fields needed; check authority on reads and exports. Information owner; try an unrelated case and a disallowed field.
SEC-R2 (Unauthorised acceptance) A person without current authority accepts ownership. Check identity, current policy, named receiver and case version when the change is committed. Service owner; withdraw permission before a queued action reconnects.
SEC-R3 (Unsafe summary use) A summary discloses private material or induces an unauthorised tool action. Restrict source facts, tool scope and retained output; treat returned text as untrusted input. Application owner; use hostile source text and verify no extra read or write occurs.
SEC-R4 (Altered records or traces) An intruder alters records or removes traces. Protect stored data, credentials and audit records; restrict administration and prepare detection and recovery. Platform and service owners; rehearse investigation and restoration.

The risk owner must assess likelihood and consequences in the real setting, agree the remaining exposure and confirm that proposed controls are effective. The risk rating and acceptance decision remain open in this example.

Access and the accepted result

SEC-A1 (Service authorisation) proposes authorisation at the service where the action takes effect. The service must check the caller’s role against trusted information. The implementation must establish the caller’s identity and the policy information it relies on, and prevent an old permission from bypassing the agreed rules for withdrawing access.

After a lost response, receipt lookup also requires current permission. An authorised repeat of X7 returns the original receipt; it does not make a second change. If the caller’s access has since been withdrawn, the service must not disclose the receipt to that caller. The accepted business event remains recorded and an authorised operator can investigate it. Security controls govern access without silently undoing accepted work.

Operation and recovery

SEC-O1 (Security operation record) links a suspicious access event to the actor, action, case reference, policy decision and result. Logs need access controls, retention and enough detail for investigation; credentials and unnecessary personal content stay out. An incident owner coordinates containment, business communication and recovery with the service and supplier owners.

The technology recovery example still applies if a restore loses accepted work. Pause affected actions, establish a trustworthy record and reconcile ownership before resuming. Include credential replacement and compromised configuration in the recovery decision.

Proposed checks

Test permitted and denied access, withdrawn permissions, separation of partner records, restricted tool actions, protected audit information and recovery when identity services are unavailable. Record expected and actual results separately in the security records. These checks are unrun.

About this edition

Refreshed for the September 2026 website update. This edition develops the earlier Architecture Portal and ASAF material; the fictional worked example was added in 2026.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects comparing and adapting their existing approach

Non-goals

  • Prescribing a mandatory method or claiming measured benefits

Limitations

  • Guidance illustrated by a fictional example; proposed designs and checks have not been implemented or run.

Next evidence sought

  • Review the guidance and try its records with a practising architect.