This notice covers the CMS SecureMe mobile app for iOS and Android.
It does not cover Cyber Made Simple, which is a separate product with different data flows and its own privacy notice. If you use both, both apply, separately.
Who we are
CMS InfoSec Ltd is the controller for the personal data described here. We are registered in England & Wales and operate from the United Kingdom.
Privacy questions and requests: privacy@cmsinfosec.com. Support: support@cmsinfosec.com.
The short version
Your answers to the checks, your vault, your account list and your score history stay on your phone. They are encrypted there and we never receive them.
Some things do leave the device, each for a reason. They are listed in full below, and the list is complete at the date at the top of this page. If we add anything to it, that date moves and we say so in the app.
Two things we hold need saying plainly, because they are the ones people assume we cannot see:
- If you set up plan recovery, we store a locked copy of your family key. We cannot open it without a passphrase you choose and we never receive.
- If you turn on monitoring, we store the addresses being watched, under a key we hold. We need it to run the check.
Both are explained in full further down.
There are no advertising SDKs, no analytics and no trackers in this app. We do not sell data.
What stays on your phone
- Your answers to the six security checks, and your score history over time.
- The vault, where you keep recovery codes and similar secrets.
- Your “If something happens to me” list. It is a list of your accounts so the people you trust can find them. It is not a legal will.
- Your incident records, claim records and evidence packs.
- The family key, unless you choose to set up plan recovery.
These are encrypted with AES-256-GCM and held in the platform’s own secure storage: the iOS Keychain or the Android Keystore. Uninstalling the app removes them.
What leaves your phone
Each row happens only when you use the thing it belongs to, except where the table says otherwise.
| What we send | To whom | Why | What we do not send |
|---|---|---|---|
| Your email address, in plain text | Have I Been Pwned, through our own server | To check whether it appears in a known data breach | Your name, your other addresses, your device identifiers |
| The first five characters of a SHA-1 hash of a password | Have I Been Pwned | To check whether a password appears in a breach corpus. The rest of the hash is matched on your phone; the password itself never leaves the device | The password, the full hash, or which account it is for |
| A phone number | Visian Systems, trading as tpscheck.uk, through our own server | Telephone Preference Service and CTPS lookup | Anything linking the number to you |
| A web address you asked us to check | Google Web Risk, through our own server | To tell you whether a link is known to be malicious | Your IP address. The lookup runs on our server, not your phone |
| An encrypted score, a display name and a push token | Our backend | Family Protect syncing and alerts | The answers behind the score |
| Your Apple or Google ID token and email address | Our backend | Signing you in, which Family Protect and Watch both need | Your password, which we never see |
| Your purchase receipt | Apple or Google, and our backend | Checking that a subscription is genuine and still active | Your card details, which we never receive |
| A locked copy of your family key | Our backend | Plan recovery, only if you set it up | The passphrase that opens it |
| Your “If something happens to me” list | Our backend | Only if you choose to share it with your plan. Encrypted under the family key | The contents, which we cannot read. The display name is not encrypted |
| Your email address, on a repeating schedule | Have I Been Pwned, through our own server | Monitoring, only if you turn it on | Nothing else about you |
| Crash and error diagnostics | Sentry | Diagnosing crashes | Anything, unless you have agreed. See below |
Plan invitations, seat counts and subscription state are also held on our backend, because a plan spanning several phones cannot work without them.
On the email address, specifically
We send it in full, in plain text, not as a hash. The breach-checking endpoint takes the address in the request path and offers no hash-prefix alternative, so there is no privacy-preserving version of this check available to us.
If you turn on monitoring, that means your address is sent on a repeating schedule, roughly once a fortnight, while the app is closed, rather than only when you press a button. That is the point of the feature, and it is your choice whether to have it on.
We say this plainly because an earlier draft of a related document said the opposite, and a privacy notice that understates what is sent is worse than one that says nothing.
On the family key
The key that decrypts your family’s scores is generated on your phone and normally stays there.
If you set up plan recovery, we store one extra copy of it, locked with a passphrase you choose and we never receive. It is locked using PBKDF2 at 600,000 iterations and AES-256-GCM, and we cannot open it without your passphrase.
This is a trade we made deliberately, and it has a cost. Before we offered recovery, the key could not be taken from our server because it was not there. Now, someone who stole our database and guessed a weak passphrase could reach it. That is why we insist on a passphrase of at least twelve characters. Recovery is optional. Skip it and no copy of your key is ever stored.
On monitoring, and the key we hold
Checking an address while your app is closed means we have to hold it. We store it encrypted, with a fresh encryption value for each entry, so two people watching the same address cannot be matched by reading our database.
Unlike your family’s scores, this is a key we hold. We need it to run the check. It is kept separately from the database, in our server’s secret storage, and it is never in the app. But we will not tell you we cannot read something when we can: anyone who obtained both our database and that key could read the addresses being watched.
Monitoring is off until you turn it on, and turning it off deletes what we hold.
Why we ask for location
To tell you whether the Wi-Fi network you are on is one you have trusted before, we need its name. Android will not give an app a network name unless it also has location permission. That is Android’s rule, not our choice.
We use it for nothing else. We do not record where you are, we do not store coordinates, and no location data ever leaves your phone. Decline it and everything works except the Wi-Fi check.
On crash reporting
Crash reporting starts switched off and only starts once you agree to it. When it is on, what goes to Sentry is the error message and whatever context the code attached. Before anything leaves, it passes through a redaction step that drops sensitive keys entirely and strips email addresses, telephone numbers and postcodes from the values and from the message itself.
Sentry is configured with no personally identifying data attached by default, no session replay, no profiling and no performance tracing, so it adds no identifiers of its own.
Why we may process your data (lawful bases)
- To do what you asked us to do. Running the checks you asked for, signing you in, syncing a plan you subscribed to, taking payment, and providing support. Sign-in sits here rather than under consent: a plan that works across several phones cannot be provided without a durable identity.
- Because you agreed. Crash reporting, push notifications, and monitoring. You can withdraw consent in the app’s settings at any time, and withdrawing it does not affect what was lawful before.
- Because we have a fair reason. Keeping the service secure and stopping abuse, balanced against your rights.
Who receives data, and where
| Recipient | Role | Where | Safeguard |
|---|---|---|---|
| Supabase | Backend, database, authentication, server functions | London region | UK and EEA processing |
| Amazon Web Services | Hosts the Supabase London region on our behalf | London (eu-west-2) | UK processing, under Supabase’s contract |
| Have I Been Pwned | Breach and password checking | Outside the UK | Transfer terms being finalised |
| Visian Systems (tpscheck.uk) | UK preference-service lookup | UK | UK processing |
| Google Cloud | Link safety checking and push delivery | Outside the UK | Transfer terms being finalised |
| Sentry | Crash diagnostics, only with consent | EU region | UK and EEA processing |
| Apple | App distribution, sign-in, payments, push delivery | Outside the UK | Apple Developer Program agreement |
We name Amazon because it is honest to describe the chain rather than stop at the first name in it: we use Supabase, and Supabase runs on Amazon in London.
Visian Systems retains audit logs of the numbers looked up for twelve to twenty-four months. That is their retention, not ours, and we are telling you because you cannot see it from inside the app.
Where a safeguard says “being finalised”, the written contract required by Article 28 is not yet signed. We would rather say that than claim a protection we cannot yet evidence. These pages are drafts and this line will change when the agreements are in place.
Every backend request is authenticated, and every database table has row level security enabled so one account cannot read another’s rows.
Third-party API keys are never shipped in the app. The checks that need one run through our own server functions, which is also why link checking and breach checking reach those providers from our server rather than from your IP address.
How long we keep things
- On your phone: until you delete the entry, reset the app, or uninstall it.
- A removed plan member: their records are deleted 30 days after they are removed.
- Monitoring, after a plan lapses: the addresses and the watch window are cleared 90 days after the watch expires, not 30. The extra time is so that somebody who renews late keeps their history rather than starting again.
- Monitoring rows nobody uses: deleted after 24 months without a check.
- Rate-limiting records: 7 days.
- Support correspondence: up to three years after the last message.
- Backend logs: up to 90 days.
The scores and shared documents we hold are encrypted with the family key, which we cannot read. If you set up plan recovery we hold a locked copy of that key, but it stays locked without your passphrase, so we still cannot open what it protects.
Display names and notification tokens are not encrypted, because we need them to show you a list and to reach your phone. Monitored addresses are encrypted under a key we do hold, as set out above.
Your rights
Under the UK GDPR you can ask us to give you a copy of your data, correct it, erase it, restrict or object to our processing, or provide it in a portable form. You can also complain to a regulator.
The app has an erasure function in settings that handles the on-device data directly. For anything held on our backend, write to privacy@cmsinfosec.com. We will respond within one month.
To complain, contact the Information Commissioner’s Office at ico.org.uk or on 0303 123 1113. We would rather you came to us first, but that is your choice, not a requirement.
Children and young people
A plan holder must be 18 or over. Because a plan can include a child’s device, we treat this as a service likely to be accessed by children and follow the ICO’s Age Appropriate Design Code.
When you add someone to a plan you tell us their age band. For anyone under 13, you must confirm that you hold parental responsibility, because a child under 13 cannot agree to this for themselves. From 13 upwards, the person decides for themselves whether their address is monitored, including an adult you are helping to set up. If no age is given, we treat the profile as a child’s and do not offer monitoring at all.
Anyone joining a plan is told, in words appropriate to their age, what the plan holder can and cannot see. The plan holder sees a score. They do not see the answers behind it.
What we do not do
- We do not scan for malware or viruses, and we are not antivirus.
- We are not a VPN and we do not filter or inspect your network traffic.
- We do not block calls or messages.
- We do not use advertising SDKs, analytics or trackers.
- We do not sell, rent or share your data for anyone else’s marketing.
Something we do not claim
The app does not use certificate pinning. Every request relies on the operating system’s own trust store, which is the platform default and is appropriate for what this app does. It is written down here because an earlier version of our documentation claimed pinning that was never implemented, and the fix for that is to say so rather than to say nothing.
Changes
If this notice changes substantively, the “Last updated” date at the top of this page moves in the same revision, and material changes are surfaced in the app.