How should supply-chain and trusted-service incidents be reported?¶

Report the trusted relationship, delivery mechanism, execution, impact and attribution as separate findings. Naming a supplier or service explains part of the route; it does not establish who caused the incident or whether the supplier knowingly participated.

This structure prevents technical trust from being converted into an unsupported conclusion about human responsibility.

Describe each evidential layer¶

A clear account should identify:

• the supplier, service, account, update or dependency involved;
• why the recipient trusted it;
• how the disputed content or instruction reached each target;
• which systems received, installed or executed it;
• the resulting activity and impact; and
• what evidence supports control and personal attribution.

Trust may be cryptographic, technical, contractual or organisational. A valid signature, an approved provider account and an established supplier relationship can each explain why activity was accepted, but they are different mechanisms and should not be collapsed into one assertion.

Precise wording helps. “The signed package executed unauthorised code” does not mean “the vendor knowingly distributed malware.” “The provider platform deployed the script” does not mean “the named provider employee authorised it.”

State the source of important conclusions¶

A supplier may provide a root-cause analysis, affected-customer list or account assessment that cannot be independently reproduced from customer records. Identify which findings the investigation corroborated and which rely on the supplier's evidence or interpretation.

Also explain material gaps caused by shared services, resellers, short retention, compromised accounts or provider containment. A conclusion can remain useful while clearly stating that dependency and its limits.