After a data leak you cut off the access, measure what left, then tell the people it belonged to.

What do you do in the first hour?

Write down the time and the source before you touch anything. The hour you became aware is the fact every deadline is counted from, and the person who told you is the person who can tell you more. A screenshot in a group chat is not a record. Put it in one document, with timestamps, and keep adding to it as you go. By the end of the week that document is the only thing standing between you and reconstructing the whole thing from memory.

Then cut off the access, choosing the blunt option over the elegant one. Revoking a key takes a minute and a careful audit of which calls used it takes a day, so revoke first. If a whole endpoint is the problem, a read-only outage you control is better than an open door you are still thinking about. Resist the urge to take the entire app down unless the app itself is the hole: an app that cannot start generates support tickets that compete for the people you need on the incident.

Keep your own credentials out of the next mistake. Apple's Developer Program License Agreement, in section 2.1, puts this on you in plain terms: you are fully responsible for safeguarding your Apple Account and authentication credentials from compromise. That matters in an incident because people start pasting keys into chat windows and sharing logins to move faster. Section 2.9 adds the other half. Any action taken by a third-party service provider you retained is deemed to have been taken by you, and you are responsible to Apple for it. A leak at your vendor is still your leak.

Finally, do not write to users yet. You have no numbers, and a notice you have to correct does more damage than a notice that arrives a day later with the correct count in it. Use the hour to decide who is doing what instead. One person owns containment, one owns the log analysis, one owns the written timeline and talks to everybody else. Three people with clear jobs beat nine people on a call.

Apple Developer Program License Agreement, last updated 13 October 2026, read 16 October 2026

How do you find out what actually left?

From the logs, in a specific order, and before anybody theorises. Find the one request you already know about, then widen outwards from it: the same token, the same address, the same hour. Four places hold the answer in most app stacks. Your server access logs, your database audit log, your object storage access log, and your auth provider. Pull the window from a day before the earliest sign to the moment you closed the hole, and keep the raw export rather than a summary of it. The habit is the same one that works when debugging a crash: read what happened before you decide what happened.

Two mobile-specific traps catch people here. The first is the app binary. Anybody can take your shipped build off a device and read the strings in it, so a key you compiled into the app has been public since the day that version went out, and every installed copy still carries it. The second is talking to the database straight from the phone. If the client holds a per-user key, then your row rules were the only thing protecting anything, and the real question is not whether the key leaked but what that key was permitted to select. Read the policy, not the intention.

Be generous about what counts as personal data, because the law usually is. Device identifiers, push tokens, IP addresses and whatever you derived from them are in scope in most places. Free text fields are worse than structured ones: people type their allergies, their address and their phone number into a notes box regardless of what the label said. Open a handful of real rows and look. The schema tells you what you intended to collect, and the rows tell you what you collected.

The clean-up usually turns up a field nobody declared, and that is its own obligation rather than a footnote. Google Play's User Data policy requires every developer to complete a clear and accurate Data safety section for every app, and puts the accuracy of the label and keeping it up to date on the developer. The same policy tells you to handle all personal and sensitive user data securely, including transmitting it using modern cryptography, and to protect all user data with appropriate security measures. If you discover a field you never disclosed, fixing the declaration is part of closing the incident.

Google Play Developer Program Policy, User Data, read 16 October 2026

Do Apple or Google have to be told?

No. Searched on 16 October 2026, the phrase data breach appears exactly once in the whole Apple Developer Program License Agreement, and the sentence points away from Apple. Section 3.3.3(C), Disclosures to Users, says you agree to notify your users, in accordance with applicable law, in the event of a data breach in which user data collected from your application is compromised. Its own worked example is sending an email to tell them there has been an unintentional disclosure or misuse of their user data. The same section says you must take appropriate steps to protect such data from unauthorized use, disclosure or access by third parties. The agreement has plenty of clauses telling you to notify Apple about other things, from a change of address to a regulatory complaint about your app, and not one of them is about a security incident.

Google Play's User Data policy is the same answer reached a different way: it carries no breach notification duty at all. The one email address in it belongs to a different situation. If you access, use or process personal information that Google made available to you and that originated in the European Economic Area, the United Kingdom or Switzerland, you have to implement appropriate organizational and technical measures to protect it against loss, misuse and unauthorized or unlawful access, disclosure, alteration and destruction, and monitor your own compliance regularly. If at any time you cannot meet those conditions, or there is a significant risk you will not, the policy says you must immediately notify Google by email and either stop processing that information or take reasonable and appropriate steps to restore an adequate level of protection. That is about losing the ability to comply, not about reporting an incident, and it only bites on personal information Google handed you.

So the clause that actually sets your deadline is the one inside Apple's sentence: in accordance with applicable law. In the European Union the GDPR gives you seventy two hours from becoming aware to notify your supervisory authority where feasible, and requires telling the affected people themselves without undue delay when the risk to them is high. United States rules are set state by state and the thresholds differ. This is the point in an incident to pay a lawyer rather than read a forum thread, and the hour you wrote down at the start is the number they will ask for first.

There is one more party who may decide to speak. Section 5.4 of the same Apple agreement says Apple may notify end users of products signed with Apple Certificates when it believes that is necessary to protect the privacy, safety or security of end users, or is otherwise prudent in Apple's reasonable judgment. You do not get a veto on that. Writing your own notice early is partly about being the first version your customers read.

As for the notice itself, keep it boring and specific. What happened, when it started and when it stopped, exactly which fields were exposed, how many people, what you have already done, what they should do now, and one address that reaches a human. Name the thing. An incident involving a third-party provider is a sentence that tells a reader you are hiding something, and it is usually also untrue, because Apple's section 2.9 already made your provider's actions yours.

Apple Developer Program License Agreement, sections 3.3.3(C) and 5.4, read 16 October 2026

Google Play Developer Program Policy, User Data, EU and UK and Swiss Data Privacy Frameworks, read 16 October 2026

What do you rotate, and in what order?

Revoke before you rotate, and work inwards from the data. A fresh key protects nothing while the old one still answers, so the first action on every item is killing the old value, and issuing the replacement is the second. Then order by distance from the records: the database first, then the keys your server holds, then anything a client could be holding, then your users' own sessions. Pick one person to do it and have them tick items off a written list, because the item everybody assumed somebody else had done is the one that is still live in a month.

Code signing is the part worth reading before you need it. Section 5.4 of Apple's agreement says you may revoke Apple Certificates issued to you at any time, and that for Pass certificates and for macOS applications distributed outside the App Store you can ask Apple to revoke them by email. It also lists when Apple will act without being asked, including your certificates or their corresponding private keys having been compromised, or Apple having reason to believe your products adversely affect the security of Apple-branded products or any other software, data, systems or networks. Apple publishes its certificate policy and practice statements on its certificate authority pages. Your Google Play signing setup is the opposite case: do not improvise there, ask Google, because it is not a self-service rotation.

Notice how much of that column is a No. Most of a leak is fixed on your own servers, in minutes, with nobody waiting on a store. The rows that need a new build are the slow ones, and on iOS review stands between the fix and your users, the same queue you went through when publishing to the App Store. That is the argument for keeping your secrets server side in normal times, not an argument to make during an incident.

Android gives you a release lever worth using deliberately here. a staged rollout on Google Play is the right default for a normal release and the wrong one for a security fix: holding the patched build at a small percentage leaves most of your users on the version with the hole in it. Push a security release wide, and keep the staged rollout for the feature work that follows it.

Then the uncomfortable one. If the leaked credentials belonged to an agency, a contractor or an old team account, rotation is not the end of it, because the account itself is the exposure. Moving the app onto a developer account you control is the only clean end state, and transferring an app to another account is a defined process rather than a favour you have to negotiate. Apple's section 2.9 is the reason to bother: whatever that provider did counts as something you did.