The brief for the principal and advisers.
An instruction changed. Establish how.
A family office receives a beneficiary-change instruction from a familiar mailbox. A callback to an established contact rejects the change. The immediate business decision is to hold the instruction while the technical team establishes the relevant account activity.
Separate fact, inference and uncertainty.
The fixture supports a sequence of account events and an altered instruction. Attribution to a particular person, the original means of access and the full data exposure remain separate questions. The report makes those distinctions visible to management and counsel.
The illustrative scope covers one designated mailbox, its identity and audit records, a retained message, the associated instruction and a verification record. Authority to acquire each source, relevant legal entities, reporting recipients and secure handling would be agreed before a real engagement.
Build an evidence-led explanation.
- Preserve the sources
Identity events, mailbox operations, retained messages and the business verification record have different evidential roles.
- Correlate identifiers
Align UTC timestamps, session context, account identity and InternetMessageId; record source clock and retention limitations.
- Classify conclusions
Distinguish events directly recorded in the fixtures from inferences requiring multiple sources and unresolved actor attribution.
- Connect to a decision
Document containment, beneficiary verification and the additional evidence needed before closing the investigation.
Normalise timestamps while retaining original values, source timezone and any known clock uncertainty. Use stable identifiers to connect records; proximity in time alone is insufficient. Preserve original exports separately from analytical working copies, and record transformations so another examiner can understand how the chronology was assembled.
Six events. Distinct evidential roles.
- E-01Identity sign-in
Session accepted from 203.0.113.27
An accepted sign-in is recorded. The address and an existing MFA claim do not identify the operator or prove a fresh MFA challenge.
- E-02Mailbox audit
New inbox rule changes visibility of invoice messages
The rule operation and account context are recorded. Actor attribution requires correlation with session and device evidence.
- E-03Mailbox access audit
Bind access references the payment conversation
Message identifiers connect the accessed items to the conversation. Audit access is not proof of human reading, intent or the full exfiltration scope.
- E-04Message trace + retained message
Changed payment instruction leaves the trusted mailbox
The retained message supplies content; the trace supports transmission. Neither alone establishes the identity of the person who composed it.
- E-05Independent verification record
Known-contact callback rejects the beneficiary change
The callback record supports a failed verification and a decision to hold the instruction. It is separate from the technical account attribution.
- E-06Response action record
Sessions revoked; rule and permissions reviewed
The response actions are recorded separately so that investigator changes can be distinguished from prior activity.
Recorded operations and message content.
The synthetic record includes an accepted sign-in, an inbox-rule change, access references, a retained changed instruction and the independent hold decision. Each statement cites the evidence item supporting it.
Actor identity and complete exposure.
An IP address does not uniquely identify a person. A token carrying an MFA claim does not prove a fresh challenge at that time. Missing device evidence and retained-log limits can prevent a definitive initial-access or exfiltration conclusion.
Inspect the synthetic normalised evidence excerpt
{
"example": "synthetic-normalised-evidence",
"date": "2026-08-18",
"timezone": "UTC",
"account": "assistant@example.invalid",
"records": [
{
"timestamp": "2026-08-18T08:42:11Z",
"id": "E-01",
"source": "Identity sign-in",
"event": "Session accepted from 203.0.113.27"
},
{
"timestamp": "2026-08-18T08:47:36Z",
"id": "E-02",
"source": "Mailbox audit",
"event": "New inbox rule changes visibility of invoice messages"
},
{
"timestamp": "2026-08-18T08:53:04Z",
"id": "E-03",
"source": "Mailbox access audit",
"event": "Bind access references the payment conversation"
},
{
"timestamp": "2026-08-18T09:06:22Z",
"id": "E-04",
"source": "Message trace + retained message",
"event": "Changed payment instruction leaves the trusted mailbox"
},
{
"timestamp": "2026-08-18T09:14:50Z",
"id": "E-05",
"source": "Independent verification record",
"event": "Known-contact callback rejects the beneficiary change"
},
{
"timestamp": "2026-08-18T09:28:19Z",
"id": "E-06",
"source": "Response action record",
"event": "Sessions revoked; rule and permissions reviewed"
}
]
}Inspect the fixture integrity record
The following SHA-256 digest is computed from the exact UTF-8 JSON excerpt above, including its indentation and with no trailing newline.
b06eef8e0dfa9cc927b5aa19c44fce4bb4cfa3585d0c12f4f2ad004f60fcc7eeA digest can detect a changed file relative to the recorded value. It does not establish source authenticity, actor identity or an unbroken handling history by itself. This digest describes generated demonstration data.
Protect the payment decision independently.
- Request channel
A principal, assistant or adviser submits an instruction. Email, voice and video are inputs to verification.
- Independent control
Resolve the correct entity, verify the beneficiary through an established contact route and document exceptions.
- Approval ownership
An authorised reviewer sees the transaction details and provides a recorded decision.
- Payment authority
The finance or banking system enforces the final permission and records the outcome.
For a principal, assistant or adviser, the critical control is an established verification route that survives a convincing email, voice or video. Confirm the relevant entity and beneficiary through the agreed independent process. Technical account findings inform the risk decision; they do not replace transaction authority, banking confirmation or the family’s advisers.
| Question | Evidence needed | Decision supported |
|---|---|---|
| Was the session legitimately controlled? | Device and token context, user interview, identity history and relevant endpoint artefacts. | Account containment and the confidence of actor attribution. |
| What information was accessed? | Audit context, retained messages, application activity and evidence availability. | A bounded exposure statement with explicit unknowns. |
| Was money transferred? | Authorised finance records and relevant banking confirmation. | Financial response; mailbox events alone cannot answer this. |
| Is the environment ready for normal use? | Revocation and permission review, validated changes and agreed recovery checks. | Return-to-service decision by the accountable business owner. |
The reasoning behind the controls.
A forensic conclusion must be explainable from the source record through every transformation to the decision it supports. This annex describes how we would structure that reasoning for the illustrative family-office case, while keeping collection authority, technical inference and business payment authority distinct.
- Acquired export
Record source, authority, query, collection time, format and known limits.
- Preserved original
Retain the acquired bytes and integrity record under controlled storage and access.
- Working derivative
Identify parsing, UTC conversion, filtering or redaction and the input that produced each output.
- Referenced conclusion
Cite the relevant records, explain the inference and preserve the limitations and handling history.
Begin with competing explanations, not an assumed perpetrator.
The changed instruction could involve a compromised mailbox, a compromised delegate, a malicious application, an external impersonation, authorised activity that has been misunderstood, or a change elsewhere in the payment workflow. These hypotheses predict different records. A familiar sender name alone does not decide between them. The enquiry should ask which account and session performed the relevant operation, which content was transmitted, and which independent records support the business decision.
Scope is built around those questions: relevant legal entities, accounts, devices, administrators, time periods and reporting recipients. For a principal or private office, access to personal correspondence is not automatically justified by access to an operational mailbox. Separate the material needed to examine the instruction from unrelated family or adviser information, and record the authority under which each source is acquired.
The acquisition plan is also an operational decision. An active compromise may require prompt containment while volatile or short-retention evidence is still being preserved. Record why an action was taken and what it could change. A new session revocation, password reset or rule deletion should be distinguishable from activity that preceded the investigation.
Technical basis: NIST SP 800-86: integrating forensic techniques into incident response ↗
Back to technical topics ↑Preserve the relationship between the source and the finding.
A cloud export is a representation produced by a service at collection time. It is not a physical image of the provider’s infrastructure. Its record should identify the source account or tenant, collection authority, collector, time interval, query, pagination, export format, tool version and known omissions. Keep the acquired export separately from working copies, and document subsequent parsing, filtering and enrichment.
A cryptographic digest detects a difference from the bytes associated with a recorded value. It cannot demonstrate that the provider’s original event was truthful, that an export was complete, or that the reference digest itself was protected. Preservation therefore combines integrity values with controlled storage, access records, documented transfers and a reproducible handling history. Where redaction is required, the redacted document becomes a separately identified derivative rather than a silent replacement for the acquired material.
Technical basis: NIST IR 8387: digital evidence preservation considerations ↗
Acquired source → identified export → documented transformation → derived event → referenced conclusionFor this sample, the JSON and its digest are demonstrative fixtures only. In an engagement, the examiner would maintain a manifest linking each input to its derived outputs and the report references using them. Another examiner should be able to rebuild a material timeline row from the retained input and documented transformation, or identify exactly why reproduction is limited.
Back to technical topics ↑A timeline needs uncertainty and identifiers, not just sorted timestamps.
An event may contain the time an action occurred, the time a service ingested it and the time the examiner collected it. Those values answer different questions. Converting a displayed timestamp to UTC makes comparison easier but does not remove source clock error, event aggregation or delivery delay. Preserve the original value and timezone alongside the normalised value and any known precision limitation.
For a controlled illustration, suppose two source clocks have known uncertainty of ±90 seconds. An event displayed at 09:06:22 and another at 09:07:00 have overlapping possible intervals. Their displayed order alone does not establish which occurred first. If the uncertainty has not been measured, do not invent a numeric interval; record that ordering remains unresolved and look for a causal identifier or independent evidence.
| Candidate link | Stronger supporting context | What the link does not establish |
|---|---|---|
| Sign-in to mailbox operation | Compatible account, session identifier where available, client context and time interval. | That a particular person operated the session. |
| Access event to message | InternetMessageId or another documented source identifier, with account and source context. | Human reading, intent or every later use of locally copied content. |
| Message to instruction | Retained content, message identifiers and corroborating business records. | Who authored a modification if the source record does not identify them. |
| Instruction to hold decision | Independently retained verification and transaction records. | The root cause of the technical account activity. |
A shared IP address can group unrelated users behind one egress point, and a subject line can be reused. Treat either as supporting context, not a unique join key. Preserve unsuccessful correlations too: a missing session match may reflect a collection gap or different identifier semantics rather than proof that the events are unrelated.
Back to technical topics ↑Interpret each event according to the service that created it.
Microsoft’s MailItemsAccessed documentation distinguishes Bind access to individual messages from Sync activity. Bind records can include InternetMessageId values and combine activity within a two-minute interval. Sync records describe synchronised folder activity, and subsequent offline access is outside the cloud audit trail. The event’s access type and client context therefore change how narrowly exposure can be described.
For the synthetic E-03 row, an access reference to the payment conversation supports a specific recorded access relationship. It does not, by itself, identify a human reader or establish a complete exfiltration boundary. A real investigation would inspect the access type, available session and client fields, record aggregation and the provider’s current audit behaviour before assigning that interpretation.
Technical basis: Microsoft Purview: interpreting MailItemsAccessed records ↗
We would also separate what each collected source contributes. Message trace can support transmission context, while a retained message supplies the content actually examined. An inbox-rule record needs its recorded parameters and timing to explain its effect. Delegate permissions, application grants and identity events can test alternative routes to an operation. The absence of one expected record matters only after checking whether that event was collected, retained and within the source’s documented coverage.
Back to technical topics ↑State why a conclusion is supported and what could change it.
The report should distinguish an observation from an inference. “The retained instruction contains a changed beneficiary” describes examined content. “The changed instruction was associated with this session” requires a defensible correlation. “This named individual caused the change” is a materially different attribution question that may need evidence outside the available digital records.
For each material conclusion, document the supporting records, contradictory evidence, collection gaps and alternative explanations that remain viable. Qualitative confidence should be tied to that reasoning. Do not attach a numeric probability merely to make the report look scientific. Where a source cannot establish the number of affected messages, provide the supported boundary and the uncertainty rather than presenting an invented exact count.
A technical peer review can challenge the joins, time assumptions and interpretation of source fields, and reproduce decisive transformations. This matters because software changes can alter the meaning of an artefact. A tool-generated label is an input to examination, not a substitute for understanding how the underlying record was produced.
Technical basis: NIST scientific foundation review of digital investigation techniques ↗
Back to technical topics ↑Translate technical confidence into a bounded business action.
The principal needs to know what can be decided now, what must remain on hold and who owns the next step. In this scenario, independent verification fails, so the instruction remains held even if the identity of the account operator is unresolved. Conversely, a successful technical cleanup does not validate a beneficiary. The payment decision must follow the office’s authorised process and the relevant banking controls.
The restricted executive brief would identify the affected instruction, the supported account activity, the immediate controls and the unresolved questions. A separate technical annex would preserve the evidence references and reconstruction method. Distribution can be tailored to the principal, designated advisers, technical responders and counsel so that recipients receive the detail necessary for their role.
Closure criteria should connect both workstreams: documented verification of the instruction, review of the relevant access paths, recorded containment actions, an explained evidence gap register and ownership of any residual monitoring. This provides a defensible handover without treating a technical report as a decision about legal liability or a guarantee that every possible source has been recovered.
Back to technical topics ↑A report that survives technical scrutiny.
- Restricted executive brief: affected business process, immediate decisions, confidence and unresolved questions.
- Evidence schedule: source, authority, acquisition time, collector role, integrity record, storage location and handling history.
- Event reconstruction: a referenced chronology that separates source observations, examiner analysis and response actions.
- Technical annex: correlation method, alternative explanations, evidence gaps and the scope of each conclusion.
- Action register: containment and verification owners, further collection priorities and criteria for closing the investigation.
Technical references
Background guidance for the methods discussed; these organisations do not endorse this illustrative example.