CMS SecureMe privacy notice

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. Where the two notices disagree about a shared supplier, this one is the accurate one for this app: the checks work differently here, and the difference is set out under On the email address, specifically.

Who we are

CMS InfoSec Ltd is the controller for the personal data described here. We are registered in England & Wales, company number 16417846, registered office The Accountancy Partnership, 70 Grange Road East, Wirral, CH41 5FE, United Kingdom.

Privacy questions and requests: privacy@cmsinfosec.com. Support: support@cmsinfosec.com.

The short version

Your answers to the checks, your vault, your Digital Estate list and your score history stay on your phone. They are encrypted there. We never receive them, unless you choose to keep a backup with your account, and that reaches us sealed with a passphrase we never receive.

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.

Four things we hold need saying plainly, because they are the ones people assume we cannot see, or assume do not happen at all:

• The app makes itself an account on our server the first time you open it, before you have agreed to anything. It has no name and no email address, just a random identifier, and our server sees your phone’s internet address when it is created.
• 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.
• If you invite someone by name, we hold that name from the moment you send the invitation, before they have installed anything or agreed to anything.

A backup is sealed on your phone before it goes anywhere. If you save a backup file into your own iCloud or Google Drive, it does not come to us. If you keep backups with your account, the sealed file comes to our server; it is locked with your backup passphrase, which we never receive, so we cannot read it.

All five are explained in full further down.

There is no advertising, no analytics or tracking by any outside company, and no profile built about you. If you agree, the app counts what people do in it as totals with nothing to identify you. 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 Digital Estate list. It is a list of your accounts so the people you trust can find them. It is not a legal will and it decides nothing about who inherits what.
• 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.

If you keep a backup with your account, a sealed copy of some of these is held on our server as well. On backups says which, and why we cannot read it.

What leaves your phone

Each row happens only when you use the thing it belongs to, except where the table says otherwise.

Plan invitations, seat counts, subscription state and what you have bought 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 day, 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 version 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 anonymous account

The first time you open the app it creates an account for itself on our server so that it can talk to us at all. This happens before you reach any consent screen, because without it nothing else can work.

It holds no name, no email address and nothing you have entered, just a random identifier. Our server sees your phone’s internet address when it is created, as it does for any request.

It is not enough on its own for the things that have to survive a change of phone. Setting up a plan or turning on monitoring both require you to sign in properly, and our database refuses those operations to an anonymous session. The reason is stated in the app: if we let you register addresses under a temporary identity, the day you replaced the phone they would belong to somebody nobody could reach, not you and not us.

An anonymous account that goes 24 months without being used is deleted, along with anything attached to it.

On backups

You can keep a backup so a new phone can pick up where the old one left off. It holds what the app has on your device: your vault entries, your answers and scores, and your family profiles.

Where it goes is your choice. You can save the backup as a file and put it wherever you like, such as your own iCloud Drive or Google Drive; a file you save yourself does not pass through us. Or you can keep backups with your account, on our server, so that reinstalling the app or moving to a new phone can pick up where you left off. The app then keeps that backup up to date by itself, and we keep the newest three.

It is locked before it leaves your phone, not after it arrives. The contents are encrypted on the device, and only then saved or sent. Whoever stores it, whether that is Apple, Google or us, holds a sealed file they cannot read.

The key is yours, and that cuts both ways. Opening a backup on another phone needs the backup passphrase you chose, which never leaves your phone. That is a way in for you, and not for us: if you lose the passphrase, nobody can recover that backup, not you and not us.

Backing up is something you switch on. If you never do, nothing leaves your phone this way.

Our “delete everything” button removes the backups kept with your account. What it cannot reach is a backup file you saved yourself. That sits in your own storage, which we have no access to, so deleting everything here leaves it there. That is deliberate, because we would rather not be able to reach into your storage, but it means removing that file is something you do yourself, and it is worth doing if you are deleting for privacy reasons rather than to start again.

If you made a backup with a version of the app from before September 2026, delete it. Those early backup files were protected far more weakly than the current ones, and a copy in cloud storage or an old email could be read by somebody determined without knowing your passphrase. Make a fresh backup with the current app and delete the old file wherever you kept it. The app warns you if it ever reads one of the old files.

On the family key

The key that decrypts your family’s scores is generated on your phone and normally stays there. It reaches other members inside an invitation locked with a passphrase you tell them separately, which our server never receives.

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-HMAC-SHA256 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.

One consequence worth stating. Every member of a plan holds a copy of the family key. If you remove someone, our server stops them fetching anything new from that moment, but they keep the copy they already had, so anything they had already downloaded stays readable to them. There is no way to undo a removal either; a removed person has to be invited again.

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. If your phone cannot reach us at the moment you turn it off, the app tells you so rather than claiming it worked.

A registration lapses by itself after 45 days without the app being opened. We are not told when you cancel anything; we simply stop being asked to keep watching.

On the names of people you invite

When you invite somebody by name, we store the name you typed alongside the invitation, so that it reaches the right person. That name is on our server from the moment you send the invitation, before the person has installed anything or agreed to anything, and it stays there for 14 days if they never accept.

If you would rather not, invite them with the group code instead, which stores no name.

On links you ask us to check

When you paste a shortened link, our server follows it to find where it leads before checking the destination. That happens on our server rather than on your phone, deliberately: following a suspicious link from your phone is exactly what whoever sent it wants, because their tracker would see your address and a single-use link would be spent. Following it from our server shows them our server instead.

The permissions we ask for, and why

Location. To tell you the name of the Wi-Fi network you are on, so you can mark your home network as trusted, we need to read that name, and neither platform will give it to an app without location permission. On Android that is Android’s rule; on iOS the same permission is what unlocks the network name. Either way it is the platform’s condition, 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 naming and trusting a network.

Camera. Only to scan a family invitation QR code. The app does not take or store photographs, and no image is ever uploaded.

Face ID, Touch ID or your Android biometric. Only to unlock your vault and to release a data export, so that someone holding your unlocked phone still cannot open either. The check happens on the device, through the platform’s own mechanism. We never receive your biometric data, and neither does the app: the operating system answers yes or no and nothing more.

Notifications. Only if you agree, and only to send you the alerts you asked for.

We do not ask for contacts, photos, the microphone or files, and those permissions are blocked in the app’s own manifest so that a dependency cannot quietly reintroduce one.

On crash reporting

Crash reporting starts switched off and only starts once you agree to it. Until you do, nothing reaches Sentry at all: not an error, not a crash, and not the session that a crash-reporting library ordinarily opens each time an app is launched.

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, creating the anonymous account the app needs to reach us, signing you in, syncing a plan you subscribed to, holding the names, key copy and shared items a plan is made of, 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. Breach and password checks, phone-number checks, crash reporting, push notifications, monitoring, and counting what people do in the app. Each is recorded separately, with the date and the version of the wording you agreed to. You can withdraw consent in the app’s settings at any time; it takes effect immediately, because every check reads your current choice before it runs, and withdrawing it does not affect what was lawful before. If we materially change what something does, the old agreement stops counting and we ask again rather than assuming.
• Because we have a fair reason. Keeping the service secure and stopping abuse, balanced against your rights.

Who receives data, and where

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.

Crash reports go to Sentry’s EU region and land in Frankfurt. They do not go to the United States, notwithstanding that Sentry is a US company.

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. 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

Every period above runs as a nightly job rather than when somebody remembers.

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, invitee 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.

The subscription record holds which product, how many seats, until when, which store and the store’s own reference, kept so that one purchase cannot switch on two plans. It holds no card, no billing address, no amount and no currency, because we never take the money.

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.

Two of those are buttons in the app rather than requests you have to make, in Settings → Privacy:

• Get a copy of your data. It produces a file containing what the app holds on your phone and what we hold on our server, plus every choice you have made. Releasing it requires your device unlock, so that someone holding your phone cannot export it.
• Delete everything. It removes your account and everything on our server, and wipes what is on the phone. If any part of it fails, the app tells you exactly what could not be removed rather than reporting success. If you own a plan, deleting your account deletes the plan, and with it every member’s shared list, handover and locked key. They are not told beforehand, so tell them yourself. It removes backups kept with your account. It cannot reach a backup file you saved yourself, for the reason given above.

For anything else, 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: under 13, 13 to 17, or 18 and over. There is no default, and not choosing is not the same as saying “adult”. 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: monitoring is not offered at all, and the score is not shared with the plan until an age is given.

Anyone joining a plan is told, in words appropriate to their age, what the plan holder can and cannot see, and how to leave. The plan holder sees a score. They do not see the answers behind it.

There is no advertising and no profiling in this app, for anyone of any age.

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, or analytics or trackers from any outside company. The only counting is the kind described above, which you have to agree to and which cannot identify you.
• 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.