In plain terms
This is what happens when something goes wrong with information — ours or yours. It says who we pull together, how quickly, and in what order we work. One thing is worth knowing up front: where the data is yours, we do the technical work and give you the facts, but the decision about whether anyone has to be notified is yours and your counsel's, not ours.
1. Purpose and scope
This plan governs how We Solve Problems, LLC responds to an information security incident — an actual, imminent, or threatened unauthorised access to, disclosure of, or loss of information we hold.
It covers our own information and the information we hold on behalf of clients. Where the information is a client’s, the reporting obligations and timelines in the Data Processing Agreement apply alongside this plan, and they control if the two ever differ.
Who decides what. We contain the incident, establish the facts, and report them. Whether an incident is a legally reportable breach, and what any notification says, is a legal determination for the affected client and its counsel. We are not a law firm and we do not make that call — see section 2.2 and Part Three section 31 of the Services Agreement.
2. Report it
Anyone at We Solve Problems who becomes aware of an actual, imminent, or potential incident reports it immediately to the Security Coordinator. Clients report to their usual support channel, or directly to the Coordinator if the matter is sensitive.
Report first, verify second. A report that turns out to be nothing costs a conversation. An unreported incident costs the window in which it could have been contained.
Information that triggers this plan
Personal information about an identifiable individual, including: name and contact details; government identifiers; account and financial details; date of birth; health information including protected health information; personnel records; credentials; and anything else a person would not expect to be disclosed without their permission.
Also: our own or a client’s confidential business information, credentials to any managed environment, and the contents of a system we administer.
What counts as an incident
Intentional and accidental acts alike, whether by our people, a client, a vendor, or an outside party. Including credential compromise, ransomware and other malware, mis-sent or mis-shared information, lost or stolen devices, unauthorised access to a mailbox or tenant, vendor breaches that reach information we hold, and physical loss of records.
And specific to AI systems: a prompt-injection attack that causes a tool to act outside its intended scope; an AI system with agentic capability taking an unintended action in a live environment; and information entering a model or vendor under terms that do not protect it.
3. Assemble
The incident team is assembled by the Security Coordinator and comprises:
- Decision-maker — an officer of the company, who owns the response strategy and any decision that commits the business
- Security Coordinator — runs the response, owns the incident log
- Technical lead — containment, forensic preservation, and restoration
- Client contact — owns communication with any affected client, so the client hears one voice
- Outside counsel, engaged where the incident may be reportable, may lead to a claim, or involves regulated data
One person may hold more than one role. Where privilege over the investigation matters, outside counsel is engaged to direct it; no one internal is acting as counsel to anyone.
How fast
| Level | Situation | Team assembles within |
|---|---|---|
| 1 | Sensitive personal information has been exposed — health, financial, government identifiers, credentials to a live environment | 1 hour |
| 2 | Other personal or confidential information has been exposed | 5 hours |
| 3 | Exposure is imminent but has not happened — a missing device, a credential believed compromised | 24 hours |
| 4 | Exposure is threatened — a former employee or third party threatens disclosure | 72 hours |
Containment does not wait for the meeting. Anyone who can stop an incident spreading does so immediately and reports it in parallel.
4. Establish the facts
The team’s first job is to find out what actually happened, and to write it down as it goes. The incident log is opened at the first meeting and maintained throughout.
What we work to establish:
- What information was involved, and whose
- How it was exposed, when, and whether it is still happening
- Which systems were affected, and what they connect to
- Whether the actor was internal or external, and whether it was deliberate
- Whether anything can be used to reach further — credentials, tokens, backups
- Whether a vendor or a client system is implicated
- What can be recovered, and from where
Evidence is preserved before remediation wherever that is possible. Where containment requires destroying evidence, the team records why.
5. Contain, remediate, restore
In order: stop the exposure continuing, remove the access that allowed it, restore service from known-good state, and verify the environment is clean before it goes back into use.
Credentials that may have been exposed are rotated. Where an AI system was involved, its permissions and connections are revoked before anything else, because an agentic system continues acting while people are still in a meeting.
6. Report to the client
Where the incident involves data we hold on a client’s behalf, we notify that client without unreasonable delay and in any case within the timeline in the Data Processing Agreement — ten business days, and materially sooner in practice.
Our report gives the client what its counsel needs to make the legal call: what happened, when it happened and when we found it, what information was involved, whose it was to the extent we know, what we have done, and what we recommend. We supplement it as more becomes known rather than waiting for a complete picture.
We support the client’s own notification work — its counsel, its forensic provider, its regulator correspondence — at our then-prevailing rates where the assistance is substantial.
7. Notify others
Law enforcement, insurers, and regulators are engaged where the facts and counsel’s advice require it. Our own carrier is notified on any incident that could become a claim, because a claims-made policy is unforgiving about late notice.
Where an incident affects our own business rather than a client’s, the decision to notify individuals is ours, taken with counsel.
8. Close it out
An incident is not closed when service is restored. It is closed when the team has:
- recorded what happened and what was done, in the incident log;
- determined what would have prevented it;
- decided what changes to systems, process, or training follow, and assigned them;
- confirmed those changes were actually made; and
- fed the result back into the risk assessment in the Written Information Security Policy.
One team member keeps watch for a defined period afterwards, because the second attempt often follows the first.
9. Review
This plan is reviewed at least annually by the Security Coordinator, and after any incident that tested it. Prior versions stay available at their own dated addresses.