Outbound integration is a trust-boundary decision. This playbook starts from no writes and adds the smallest authorized path with observable, reversible steps.
Confirm the default state
Deploy or connect the adapter with every outbound class disabled. Attempt a representative write for each class and verify that it is denied before any network delivery. The audit event should name the connector, class, record, actor or process, policy decision, and correlation identifier.
A missing policy entry is deny. A newly introduced record class is deny. Connector credentials alone never grant direction.
Define the two gates
The first gate enables an outbound class for the connector and tenant, such as operations or asset state. The second gate authorizes the individual record or controlled workflow. Both must pass at send time.
Document who may change each gate and apply maker-checker review to broad class enablement. Scope credentials so a policy defect cannot write unrelated classes at the destination.
Dry-run the intended writes
Use dry-run mode to render the destination, method, payload summary, classification, and policy decision without sending. Review samples that include ordinary records, sensitive records, stale versions, and records from another tenant.
Do not log secrets or full protected payloads in the dry-run evidence. Store hashes and selected safe fields sufficient to compare the later send.
Enable and observe
Activate one class in a controlled window, then authorize a small set of records. Watch request counts, acknowledgements, destination identifiers, retries, denials, and dead-letter events. Reconcile source records to destination results.
Every successful write records the exact policy version and payload hash. A queued record is re-evaluated at send time rather than inheriting authorization from enqueue time.
Handle retries and partial failure
Use idempotency keys derived from a stable operation and version, not a random value per attempt. Distinguish retryable transport failure from permanent validation or authorization failure. Bound retries and move exhausted work to a reviewable dead-letter state.
For multi-record operations, state whether delivery is atomic or individually reconciled. Never label a batch successful when only some records were accepted.
Revoke safely
Disable the record gate for targeted revocation or the class gate for a whole path. Verify that queued and retried writes are blocked immediately. Rotation or removal of destination credentials is a second containment step, not the primary policy mechanism.
Revocation does not erase earlier writes. Preserve their audit trail and follow the destination’s correction or deletion process where appropriate.
Evidence checklist
- Default-deny tests cover known and newly introduced classes.
- Class and record gates have named owners.
- Dry-run samples were approved without exposing protected payloads.
- Delivery uses stable idempotency and bounded retry.
- Success, denial, failure, and revocation are all auditable.
- Cross-tenant and unauthorized-record tests remain denied.