Security breaches: what they mean for a design studio

Security breaches are incidents in which someone without permission gets into a system, account or file store and can see, copy, change or delete what is inside. For a web designer or small agency, the realistic version is rarely a movie-style hack. More often it is a phished email password, a public share link that never expired, or a former freelancer who still has CMS access. If client personal data was exposed, the breach can also start a legal notification clock. That makes the first decision a matter of who acts, not only what went wrong.

Incident, security breach, data breach: three words, three different jobs

The terms get used interchangeably in news coverage. In practice they decide who has to do what, so they are worth separating before anything goes wrong.

Security incident

A security incident is any event that threatens the confidentiality, integrity or availability of a system or data. A blocked login attempt from an unknown country is an incident. So is a malware warning on a downloaded font file. Most incidents end with "nothing got through", and they still deserve a line in a log.

NIST's incident response guidance, SP 800-61 Revision 3, (published April 2025) treats incident response as part of ongoing cybersecurity risk management rather than a one-off firefight and is written as a community profile of the Cybersecurity Framework 2.0, whose functions are govern, identify, protect, detect, respond and recover. For a five-person studio, that translates into a plain rule: decide who owns the response before you need one.

Security breach

A security breach is an incident where the protection actually failed: an unauthorized person or program got access. The attacker is inside the mailbox, the drive or the WordPress admin. Whether data was taken is a separate question you answer later.

Personal data breach under GDPR

The GDPR uses a narrower and more consequential term. Article 4(12) of the Regulation defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. Two details in that sentence matter for studios:

• "Accidental" counts. A client contact list emailed to the wrong person is a personal data breach without any attacker involved.
• "Loss" and "destruction" count. A ransomware infection that encrypts a client's customer export is a breach even if nothing leaves your network.

Seven ways security breaches happen in design and agency work

The ranking lists of record-size breaches describe what happens to large companies. A studio's exposure looks different: smaller volumes, but spread across far more tools and people. These seven patterns cover much of what a design team can actually influence.

Two of these need no attacker skill at all. Misdirected sharing and leftover access are process failures, and they are the ones a handoff workflow controls directly.

Credentials in the brief are a breach waiting to happen

A common studio-specific risk is login data travelling in plain text: hosting passwords pasted into an email, CMS credentials in a shared document, a domain registrar login in a chat thread. Once credentials sit in a mailbox, every account that can read that mailbox can read the credentials. The fix is boring and effective: ask clients for a dedicated user account with the role you need, not their own password, and record in the brief which accounts exist and who owns them.

"Anyone with the link" often has no expiry date

Share links feel temporary because you created them for one task. Many tools keep them active until someone switches them off unless you set an expiry date. Before the end of the year, open the sharing overview of each drive you use and filter for public or link-based shares. Anything belonging to a closed project gets revoked.

Count the copies: where one client file ends up

Breach exposure grows with the number of places a file lives. A useful exercise is to trace one real file through your workflow and count every copy. Here is a worked, fictional example: a client sends a spreadsheet with 40 employee names and photos for a team page.

The email route

• Copy 1: the client's sent folder
• Copy 2: the shared studio inbox, read by three people
• Copy 3: the designer downloads it to a laptop
• Copy 4: the designer uploads it to the project drive
• Copy 5: the designer forwards it to the developer (developer inbox)
• Copy 6: the studio's sent folder
• Copy 7: the developer downloads it locally
• Copy 8: the developer imports it into the staging CMS

That is eight copies across five systems (two mail servers, two laptops, one drive and one CMS, with the staging site counted as part of the CMS host), and three of them sit in mailboxes nobody will think of when the project closes.

The single-intake route

The client uploads the file once to a project intake point. The team works from that one location, and the export lands in the project folder at handoff. Count again: intake storage (1), project folder after export (2), staging CMS (3). Three copies across three systems.

The formula behind both counts is simple:

Exposure points = copies × systems those copies sit in

Email route: 8 × 5 = 40. Single intake: 3 × 3 = 9. The numbers are not a risk percentage; they are a way to compare two workflows on the same scale. When a breach happens, every exposure point is a place you have to check, so the second number also describes how long your investigation will take.

This is the logic behind running briefs and uploads through one link instead of email chains: fewer copies, fewer systems, a shorter list of places to search after something goes wrong. Whatever tool you use, run the copy count on one live project and write the result into your project notes.

The first 72 hours after a breach

Within the GDPR's scope, the Regulation sets the clock. Under Article 33, the controller notifies the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people's rights and freedoms. A notification made after 72 hours has to include the reasons for the delay. A processor notifies the controller without undue delay after becoming aware of the breach. Article 34 requires the controller to inform the affected individuals without undue delay when the breach is likely to result in a high risk to their rights and freedoms.

For most studios, the client is the controller of the data in their files, and the studio acts as processor. That means your first external call is usually to your client, not to the authority. Check your data processing agreement for the exact contact path and any agreed time frame.

Hours 0–4: contain

• Reset the affected password and sign out all sessions.
• Remove unknown forwarding rules, OAuth app grants and devices.
• Revoke public share links on the affected drive.
• Do not delete logs, emails or files you suspect were touched. They are your evidence.

Hours 4–24: scope

Answer four questions in writing, with timestamps:

• Which account or system was accessed, and since when?
• Which clients' files were reachable from it?
• Do those files contain personal data, and what kind (contact details, photos, ID documents, payment data)?
• Is there evidence of download or change, or only of access?

The copy count from the previous section pays off here. If a client's files lived in one intake location and one project folder, question 2 takes minutes. If they were scattered across inboxes, it can take a day.

Hours 24–72: inform and document

Send the affected client a factual note: what happened, when you noticed, which of their data was reachable, what you have already contained, and who their contact is. Do this without undue delay; do not hold the note back until hour 72. Leave the risk assessment and the authority notification to the controller unless your contract says otherwise. Article 33(5) requires the controller to document any personal data breach, including the facts, its effects and the remedial action taken, so your timeline becomes part of their record.

Outside the EU, notification rules differ by country and, in the US, by state. If you work with clients in several jurisdictions, list in each contract which law applies and who notifies whom.

Why a December breach is harder to handle

Year-end timing matters. The 72-hour window in Article 33 is written in hours, not working days. Holidays reduce the people available, not the deadline.

If the controller becomes aware of a breach on the afternoon of 23 December 2026, the 72-hour mark falls around 16:00 on Saturday 26 December, and almost all of the window lies on Christmas Eve, the Christmas holidays or a weekend in many countries. The EU's general rules on time limits (Regulation No 1182/71, Article 3(4)) push a deadline to the next working day only for periods expressed otherwise than in hours, so do not plan on the holidays extending a 72-hour window. Edge cases are a question for the client's data protection contact or a lawyer, not for a studio to guess at during the incident.

The practical consequence for a studio is a holiday coverage plan, written before the office closes:

• One named person per week who checks the studio inbox and security alerts daily.
• A phone number for each active client's responsible contact, not only an email.
• Admin access to email, drive and hosting accounts held by at least two people, so a breach does not wait for the one person on holiday.
• A printed or offline copy of the runbook above, in case the compromised account is the one holding it.

December is also when freelance contracts end and year-end archives get built. Both create leftover access. Offboarding a freelancer means removing them from every system they touched, not only the project board.

A 20-point exposure audit before the holidays

Ten checks, scored 0 (no), 1 (partly) or 2 (yes), for a maximum of 20 points. Use it once before the end-of-year break and once after the first project in January.

Reading the total (maximum 20):

• 16–20: Maintain. Repeat the audit each quarter.
• 10–15: Fix the lowest-scoring lines before your last working day of the year. Lines 3, 4 and 6 tend to be the quickest wins because they need no new tool.
• Below 10: Treat lines 2, 3 and 10 as blockers. In this state, a breach can easily run past the 72-hour window simply because nobody can reach the right account.

The audit is a decision aid, not a certification. A high score says your workflow has fewer gaps you can see; it does not prove the absence of a breach.

What a breach can mean for the people in the files

Studio work often involves other people's personal data: a client's staff photos for an about page, customer testimonials with full names, newsletter export files for a migration. Those people never chose your studio, and they bear the consequences if the files leak.

The GDPR's Recital 85, in the same Regulation, lists kinds of damage a personal data breach can cause if it is not addressed in an appropriate and timely manner, including loss of control over personal data or limitation of rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation and loss of confidentiality of personal data protected by professional secrecy. For a design studio, the decision rule follows from that list: if a file could enable fraud or identity theft (ID scans, signed contracts, bank details), it should not enter your project folder at all unless the work requires it, and it should leave at handoff.

Ask clients to strip spreadsheets down to the columns the design needs. A team page needs a name, a role and a photo. It does not need birth dates, private phone numbers or the HR system's employee ID.

FAQ

What does "account breach" mean?

An account breach means someone other than the owner signed in to an account, usually with stolen or guessed credentials. Signs include sign-ins from unknown devices, new forwarding rules, changed recovery email addresses and messages you did not send. Reset the password, end all sessions, review connected apps and check what the account could reach.

Is every security breach a data breach?

No. A security breach means protection failed and access occurred. It becomes a personal data breach under the GDPR when personal data was destroyed, lost, altered, disclosed or accessed as a result. An attacker who gets into a mailbox containing no personal data has caused a security breach but not a personal data breach, though such a mailbox is rare in client work.

Does my agency notify the data protection authority?

In most client projects, the client does. Under Article 33, the controller notifies the authority, and the processor informs the controller without undue delay. Most studios process client data on the client's behalf, which makes them processors. Your data processing agreement should name the contact path; if you have none, set one up before your next project starts.

Why do "largest breach" lists disagree?

They count different things: records, accounts, unique people or files, often based on figures the breached company or outside researchers reported, which can change as investigations continue. For a studio, those lists are less useful than the copy count of your own workflow, because your exposure is set by where your clients' files sit, not by the size of other companies' incidents.