IT security intelligence. Since 2006.Cloudflare services ↗
FAMILY OFFICE / DIGITAL INVESTIGATIONS

From a trusted instruction to an evidence-led decision.

A family-office investigation separates recorded events, technical inference and unresolved attribution before informing the next decision.

ILLUSTRATIVE TECHNICAL EXAMPLE

Synthetic scenarios and reference designs demonstrate the structure and depth of a deliverable. They are not client case studies, production findings or verified performance claims.

TRUST-IT / EX-02EXECUTIVE READOUT + TECHNICAL ANNEXREFERENCE EDITION 02

The brief for the principal and advisers.

SCENARIO / TRUSTED MAILBOX

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.

REPORTING DISCIPLINE

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.

CONTROL MAP / EVIDENCECorroborate the event before attributing the actor
Corroborate the event before attributing the actorIdentity, mailbox and message records are correlated using timestamps and stable identifiers. The final analysis separates established events, supported inferences and unresolved questions.SOURCE RECORDS / DIFFERENT SIGNALS, DIFFERENT LIMITATIONSIdentity activityE-01 · session contextMailbox operationsE-02 / E-03 · audit IDsMessage + business recordE-04 / E-05 · message IDsUTC-normalised correlationPreserve provenance · test alternatives · record gapsEstablished eventsWhat the records directly showSupported inferenceWhat corroboration supportsUnresolved questionsWhat the record cannot prove
  1. Preserve the sources

    Identity events, mailbox operations, retained messages and the business verification record have different evidential roles.

  2. Correlate identifiers

    Align UTC timestamps, session context, account identity and InternetMessageId; record source clock and retention limitations.

  3. Classify conclusions

    Distinguish events directly recorded in the fixtures from inferences requiring multiple sources and unresolved actor attribution.

  4. Connect to a decision

    Document containment, beneficiary verification and the additional evidence needed before closing the investigation.

Identity, mailbox and message records are correlated using timestamps and stable identifiers. The final analysis separates established events, supported inferences and unresolved questions.

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.

18 AUG 2026 / UTCEntirely synthetic chronology
  1. E-01
    Identity 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.

  2. E-02
    Mailbox 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.

  3. E-03
    Mailbox 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.

  4. E-04
    Message 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.

  5. E-05
    Independent 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.

  6. E-06
    Response action record

    Sessions revoked; rule and permissions reviewed

    The response actions are recorded separately so that investigator changes can be distinguished from prior activity.

ESTABLISHED IN THE FIXTURE

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.

NOT ESTABLISHED

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.

b06eef8e0dfa9cc927b5aa19c44fce4bb4cfa3585d0c12f4f2ad004f60fcc7ee

A 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.

CONTROL MAP / FAMILYA trusted message still crosses an approval boundary
A trusted message still crosses an approval boundaryA principal, assistant or adviser can initiate a request. The family office validates entity, purpose and beneficiary independently before authorised finance staff release a payment in the banking system.PRINCIPAL / ASSISTANT / ADVISER → FAMILY OFFICE → AUTHORISED FINANCEInstruction receivedTrusted-looking channelIndependent checkEntity + beneficiaryAuthorised decisionNamed owner + recordFinance / bank controlSeparate release authorityAPPROVAL BOUNDARY: MESSAGE APPEARANCE DOES NOT GRANT PAYMENT AUTHORITY.TECHNICAL INVESTIGATION AND BUSINESS VERIFICATION INFORM DIFFERENT DECISIONS.
  1. Request channel

    A principal, assistant or adviser submits an instruction. Email, voice and video are inputs to verification.

  2. Independent control

    Resolve the correct entity, verify the beneficiary through an established contact route and document exceptions.

  3. Approval ownership

    An authorised reviewer sees the transaction details and provides a recorded decision.

  4. Payment authority

    The finance or banking system enforces the final permission and records the outcome.

A principal, assistant or adviser can initiate a request. The family office validates entity, purpose and beneficiary independently before authorised finance staff release a payment in the banking system.

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.

Questions that shape the next workstream
QuestionEvidence neededDecision 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.

CONTROL MAP / EVIDENCE-LINEAGEMake every transformation traceable to its input
Make every transformation traceable to its inputAn acquired export is preserved as an identified original. Documented transformations create separately identified working derivatives. A finding cites those derivatives and their source records. A provenance manifest records acquisition, integrity, transformation and handling information; hashes alone do not prove authenticity.COLLECTION → PRESERVATION → ANALYSIS → REPORTINGAcquired exportSource + collection scopePreserved originalIdentified acquired bytesWorking derivativeTransforms documentedReferenced findingObservation + inferencePRESERVE ORIGINAL VALUES. IDENTIFY REDACTED AND NORMALISED COPIES AS DERIVATIVES.Provenance manifestAuthority · collector · query · time · transformations · integrity values · handling historyINTEGRITY ≠ AUTHENTICITY ≠ COMPLETENESS. EACH REQUIRES ITS OWN SUPPORTING RECORD.
  1. Acquired export

    Record source, authority, query, collection time, format and known limits.

  2. Preserved original

    Retain the acquired bytes and integrity record under controlled storage and access.

  3. Working derivative

    Identify parsing, UTC conversion, filtering or redaction and the input that produced each output.

  4. Referenced conclusion

    Cite the relevant records, explain the inference and preserve the limitations and handling history.

An acquired export is preserved as an identified original. Documented transformations create separately identified working derivatives. A finding cites those derivatives and their source records. A provenance manifest records acquisition, integrity, transformation and handling information; hashes alone do not prove authenticity.
01

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 ↑
02

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 ↗

Proposed analytical lineageAcquired source → identified export → documented transformation → derived event → referenced conclusion

For 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 ↑
03

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.

Correlation decisions for the illustrative investigation
Candidate linkStronger supporting contextWhat the link does not establish
Sign-in to mailbox operationCompatible account, session identifier where available, client context and time interval.That a particular person operated the session.
Access event to messageInternetMessageId or another documented source identifier, with account and source context.Human reading, intent or every later use of locally copied content.
Message to instructionRetained content, message identifiers and corroborating business records.Who authored a modification if the source record does not identify them.
Instruction to hold decisionIndependently 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 ↑
04

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 ↑
05

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 ↑
06

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.
APPLY THIS DEPTH TO YOUR SCOPE

Bring a decision that needs evidence.

Discuss the systems, responsibilities and deliverables that matter to your organisation or private office.

Discuss a confidential scope Explore the related service All technical examples

What’s your next
technology challenge?

TRUST-IT / FIND YOUR NEXT STEP

How can we help?

Popular topics

Search the public TRUST-IT website.