Supplier support data: map the copies

Supplier support data belongs in your supplier review even when it sits outside the product your business buys. A sales-call summary, support attachment or customer conversation can contain information that never appears in the production application's data map. Decide which of those copies your business has supplied or has reason to investigate, and give each category an owner. Do not close the question solely because the main product record looks complete.

A supplier data inventory describes what information the relationship involves, where it may be held and who can explain it. It should distinguish a record your team knows it shared from a supplier-created summary whose contents you have not seen. Neither observation, by itself, establishes that a particular copy was obtained during an incident.

That distinction matters when an incident notice concerns sales or support systems. It also matters during ordinary procurement and renewal, when an organisation needs to understand the information retained around the service as well as inside it.

What WorkOS's November update shows

In its 6 November 2026 incident update, WorkOS says an internal tool aggregated information from its customer relationship management, support and customer-communication systems. It identifies 25 October as the first confirmed unauthorised access and 30 October as the date of bulk retrieval. This is a later investigation update, not a claim that the incident began on publication day.

WorkOS says its investigation found that only data in its sales and customer-support systems was affected, and that an independent forensics firm validated its findings. Its disclosed categories include business contact details, account histories, summaries and excerpts of sales calls, support discussions and customer Slack conversations. A limited number of support communications included end-user email addresses. It also lists product usage and connection or directory-health information.

These are the vendor's reported findings. They do not identify the records belonging to a particular reader or establish that every customer had every category exposed. The practical question is whether your own supplier relationship creates copies in those categories. A production-service inventory cannot answer that on its own.

Follow the relationship as well as the product

Begin with the people who deal with the supplier. Procurement may hold the presales correspondence, a technical team may own tickets, and an account manager may attend service reviews. Each can know about a different part of the information shared. Asking only the application owner can leave those records unexplained.

For one supplier, trace an ordinary sequence: the evaluation before purchase, a support request after launch and a later account review. Use authorised business records to establish what your team actually supplied. Record the reference, date, category and owner without copying confidential contents into a general spreadsheet.

Then ask what the supplier creates from those interactions. A meeting invitation proves a meeting was arranged; it does not establish the contents or retention of a supplier's notes. A ticket attachment retained in your own system can show what you sent, while leaving the supplier's current copies and internal summaries unresolved. Make that difference visible.

The ICT supplier risk guide covers the wider relationship, including contracts, assurance and responsibilities. The narrower task here is to add the sales and support records that the main service description may omit, then decide who will assess and control them.

A fictional business traces three overlooked records

Consider a fictional software business reviewing an identity-service supplier after a notice about sales and support systems. All suppliers, records and outcomes in this example are invented. It illustrates an inventory decision, not a finding about a WorkOS customer.

Application owner Tom initially offers the product data map. It describes the information used by the live application but contains no entries for the purchasing or support relationship. Privacy lead Amira asks procurement owner Jo and support lead Maya to trace their own authorised records before accepting that map as the full account.

Jo finds a presales message that supplied named business contacts and a description of the proposed rollout. Maya finds ticket T-41 and the local copy of a diagnostic attachment sent with it. The attachment contains a small set of end-user email addresses used to illustrate a reported fault. Jo also finds the invitation and agenda for a supplier account-review call. The supplier's internal call summary is not available to the business.

They complete the following category record. The references point to restricted originals; the review does not reproduce the addresses or diagnostic material.

The first supplier reply discusses the core identity product and links to its standard product documentation. Jo tests that reply against the actual request. It does not answer where sales correspondence, ticket attachments or call summaries are held. She marks the reply insufficient for those questions and asks the supplier's designated contact to route them to the appropriate owner.

That failed evidence check changes the outcome. Tom's product map remains useful for its original purpose, but the business does not accept it as a complete supplier inventory. Amira includes the confirmed support-attachment category in the assessment without claiming the particular attachment was taken. The call-summary entry remains explicitly unverified rather than disappearing from the review.

Complete the inventory decision without inventing a supplier answer

Maya checks the sent attachment against the ticket reference and confirms that the local record is the material submitted, rather than an unrelated draft. Jo checks the presales message and meeting records in the same way. This repeat review establishes the business's evidence of sharing and the limits of its knowledge. It does not inspect the supplier's systems.

At the agreed management review, the supplier still has not provided the missing copy information. Amira accepts the inventory correction as complete for the records examined: the relationship now includes confirmed presales and support categories, plus an unresolved possible meeting-summary category. She keeps the supplier evidence request and any incident assessment open. The record distinguishes completion of the internal mapping work from closure of the external uncertainty.

The business assigns further decisions separately. Jo owns obtaining a scoped supplier answer about the sales and meeting records. Maya owns the support information-sharing process. Amira owns assessment of the information involved and any specialist privacy or legal questions. Tom continues to own the production product map. Nobody becomes responsible for all four simply because they received the incident notice first.

If the supplier cannot provide a particular record, Jo asks whether it can still explain the relevant categories, purposes, retention arrangements and access responsibilities. That may help the review without resolving the exact contents of a call summary. Any remaining gap retains its effect on the decision and an escalation owner. An unavailable copy is not evidence that no copy exists.

Change future sharing without erasing the historical question

The fictional business also finds that its support process encourages staff to attach an entire diagnostic export when a small example may be enough. Maya agrees a revised preparation step with the technical team. Staff should first establish what the supplier needs and whether a fabricated or reduced example can explain the fault. Where real information is necessary, the responsible owner must approve the route and scope under the business's procedures.

Maya tests the revised instruction using an invented support problem and a fabricated export. The first prepared attachment still includes an unnecessary email-address field. She records the failed check, corrects the instruction with the technical owner and repeats it. The second review confirms that the example retains the fields needed to explain that test problem and excludes the unnecessary field. No real ticket is submitted in this exercise.

Amira accepts that process change for the tested task. It does not prove that every future diagnostic can omit the same fields, or that removing an address always makes information anonymous. Maya owns reviewing exceptions and checking that staff can still provide useful support evidence. A vague instruction to "remove sensitive data" would leave those judgements to each person without help.

This adds preparation and review work. Reducing an attachment too far can make a fault difficult to reproduce, while sending an unrestricted export can create copies the business did not intend. Agree the necessary information with the support provider and retain the reason for exceptions. Do not promise that a new internal rule removes material already held elsewhere.

Historical records need their own treatment. If deletion or retention changes are appropriate, the responsible owner should establish the applicable arrangements and any evidence-preservation needs before requesting or making changes. Deleting the local attachment would not establish deletion of the supplier's copy and could remove the business's evidence of what it sent.

Keep category mapping separate from exposure and duties

The completed outcome is an expanded, owned inventory and a tested improvement to future support preparation. It is not a conclusion about every record affected by an incident. The business has evidence for what it supplied, a clear question about supplier-created records and identified owners for the remaining decisions.

Where an incident is involved, the privacy and incident leads should assess the available information through the organisation's established process and obtain appropriate specialist advice. Do not wait for a perfect inventory before considering actions that may already be needed. This article sets no notification threshold or deadline and cannot decide a particular organisation's legal duties.

If later evidence changes an earlier incident account, the Legal Aid Agency scope-review article explains that separate decision. Here, the purpose is to stop sales and support copies being omitted in the first place. A supplier's next answer should be checked against the specific category and question it addresses, not treated as clearance for the whole relationship.

Bring one overlooked copy to a compliance review

Choose one supplier and a recent support or sales interaction. Identify the authorised record owner, what was shared, what the supplier may have created and which answer is missing. Keep the source material restricted and use references in the review. That provides a concrete starting point without gathering every conversation into a new uncontrolled archive.

My IT compliance support can help scope a gap assessment, an evidence plan and named responsibilities for the controls under review. The work can connect the inventory findings to prioritised remediation within an agreed scope. It does not replace incident forensics or specialist decisions about legal notification.

Discuss your supplier support data review with a redacted description of the overlooked category and the question your current evidence cannot answer. We can agree what needs reviewing, who owns the missing evidence and which control changes require further assessment.