Security overview

Servers and the database run in the Netherlands. Uploaded files and the backup copies of the database are stored in the EU (Cloudflare R2, EU jurisdiction). Both stay inside the European Economic Area.

Three companies handle information for us:

• Railway runs the servers and the database.
• Cloudflare stores uploaded files: training certificates, photos of vehicles and places, documents shared within an area, and the photographs and voice notes attached to incident reports. Every file is encrypted before it is stored — see below. It also keeps the nightly backup copies of the database, which it cannot open.
• Google delivers notifications to the Coccu Android app. Google sees only fixed words — “Something new for you”, or “EMERGENCY” for a help alert — and a link to a record, never a name, a place or the message. The words are read from Coccu once it is opened.

In a web browser, notifications pass through the push service of the browser's maker — for example Google for Chrome, Mozilla for Firefox, Apple for Safari, Microsoft for Edge. The browser picks the service, not us. A browser gets the same fixed words as the app, and they are encrypted on their way through: the service sees that a notification reached a device, and when, but not what it says. Notifications are the one path that may leave the European Economic Area.

Maps use imagery from OpenStreetMap, but a member's device never contacts them. Map imagery is fetched by our server, so no third party learns who is looking at a map, or where.

• Each area of operations is walled off from every other. A member sees only the areas they belong to. An organization running several areas decides, per person, which ones.
• Missions are need-to-know. A person sees the missions they are on, lead, drive, guard or asked for, and the managers see all of them. Nobody else sees a mission exists.
• Incident reports can be filed by any member. A report names the people involved and what happened to each of them, such as a severe injury: that is health data. The full report is read only by the Security Manager, the Operations Manager and the Director. The people on the mission it happened on see a short line: what happened, how serious, and who reported it. A photograph or voice note attached to a report reaches the managers, the people on that mission and the person who filed it, and nobody wider.
• Training certificates are visible only to the person they belong to.
• Uploaded files are never at a public address. Every file is served only after the platform has checked that the person asking is entitled to it, and browsers are told not to keep a copy.
• Live positions are shown only to the people following that mission, and only for the people who chose to share them. Where an area has a curfew, the curfew board says only how old a team's last position is and where it was, in words (below).
• Going out, where an area uses it, and teams on missions where it has a curfew, are seen by the radio room, the Security Manager and the Director, on one board, and by nobody else, except that while a Security Manager or a Director is away, the colleague named to stand in for them sees the board too. A person whose only role is the radio room is refused everywhere else in the platform: missions, people, places, documents and files.

• Passwords are stored as one-way hashes. Nobody at Coccu can read one.
• Two-step sign-in is required for every managerial role, for Directors and for the radio room, and is available to everyone else. It uses the standard time-based codes that any authenticator app produces. A code can be used once. A phone or laptop can also be added as a passkey, so the second step is a fingerprint, face or screen lock instead of a typed code; the code stays as the way back in.
• Sign-in attempts are limited by network address, so a password or a code cannot be guessed by trying many times.
• A member can sign out every other device from the one in their hand. If a phone is lost, that is the first thing to do.
• Everything between a device and Coccu travels over HTTPS.

The fields where the sensitive content actually lives are stored sealed, so a copy of the database on its own does not reveal them:

• Phone numbers, on profiles and on mission travellers.
• Incident reports: the description, where it happened, the notes on damage and reputation, the comments and history notes, and the injury details — whether anyone was hurt, how many, how badly, and what happened to each person involved.
• The Security Manager's route assessment and safe havens on a mission.
• Risk assessments at every level: the notes, mitigations, sources, stakeholders and early-warning indicators written against each risk, for the area, each risk zone and each mission.
• What was said after a mission: the account of how it went, and any deviation notes.
• Going out and curfew: where a person said they were going, in their own words; where a team said it was in for the night; what the radio room noted after reaching somebody; and why Security brought curfew forward for a night.
• Two-step sign-in secrets.
• Every uploaded file — certificates, photographs, voice notes, documents — is encrypted before it is stored, under a key derived from the same secret.

Names, email addresses, reference codes and the risk grades themselves are not encrypted, because the platform sorts, searches and bands on them. The encryption key is held separately from the key that signs sessions, so neither can be used to reach the other. A place picked from the area's own list when going out is stored by its name, not encrypted, like the list itself.

Backups. Once a night a full copy of the database is made. It is encrypted before it leaves the server, with a key only Coccu's owner holds: neither Railway nor Cloudflare can open it, and the sealed fields above stay sealed inside it. A lock on the storage means a copy less than 27 days old cannot be deleted or changed, even by someone who has broken into the servers. Once a month a copy is restored into a test database to prove it works; the test database is deleted in the same sitting.

• Nothing is sent unless the organization has turned location sharing on for the area and the person has turned it on for themselves.
• A position is sent only while a leg is being travelled: after the departure check-in and before the arrival. Nothing is sent between legs, before a mission, or after it, unless the Security Manager asked for the whole mission, which the mission screen says.
• At a place nobody has pinned on the map yet, pressing “arrived” or “left” also records where the phone was, so whoever adds the place can use the spot. It is deleted as soon as the place is pinned, or with the trails, whichever comes first — and only under the same two conditions as sharing.
• A person can stop sharing at any time, mid-journey, from the mission screen. Nobody is told that they did.
• Going out sends no position at all. The board shows only what the person said: where, and when they will be back.
• A help alert — the red button on every screen — sends the person's position to the area's managers and their mission's focal point every 15 seconds until they, or a manager, stand it down. Those positions are deleted on the same clock as other positions. If an incident report is written from the alert, they are kept with the report instead.
• Positions delete themselves after 30 days unless the organization sets a different period.
• The coverage map, which shows where phones lose signal, is built from counts per square of about 500 metres. It holds no person and no mission. Where a phone running the Android app reported the name of its mobile network, the square also counts per network, so the map can say which one works there; that breakdown holds no person and no mission either.
• A notification says only that there is something new — “EMERGENCY” for a help alert — in the app and in a browser alike. No place, no time, no name and no mission appears on a locked screen; the details are read in Coccu once it is opened.

An area can set a curfew, and can let staff record going out after hours, outside any mission.

• Off by default. The Director turns Going out on per area, chooses which staff are offered it (international, national, or staff type not recorded), and whether the button reads “Required by your security rules” or “Optional”. That is a label: nobody is stopped from leaving without pressing it.
• What an entry holds: who went, any colleagues going with them (picked from the area's members, never typed), a place from the area's list or up to 60 characters of free text, when they left, when they said they would be back (within 24 hours), and when they were back. The screen asks for where, not why. No position.
• The chase, only where the area has curfew alerts on (reminders on, plus Going out for evenings out, or mission planning for teams on missions): a reminder to the person half an hour before curfew; at curfew, the radio room, counting only holders who have two-step sign-in, or the Security Managers where there are none (with the stand-in of one who is away, or the Directors when the seat is empty; nobody, if the area has none of these); Security a set time after curfew (or after the person went out, if later), the area's grace time, 30 minutes by default, whether or not the radio room has called, at once after “No answer”, or at the promised time plus the grace time after “On their way”. At that step, Security means the Security Managers and the Directors, and the stand-in of any of them who is away. The radio room may call; the platform does not make it. Where alerts are off, nobody is alerted about an entry made from then on, and the board says so. An entry made while alerts were on is still chased to its end; teams on missions are not, their chase stops when alerts go off. The 48-hour close below tells Security whatever the switch says. If the radio room notes somebody safe for the night, that person is told at once, and so is Security where the area has a curfew. Messages inside Coccu may name the person, never the place. When the person is back, those who were told are told that too.
• The board, “Who is out”: people out now and back tonight, with where they said they were going, when they left and are due back, their phone numbers, the radio room's notes, and whether Help has been pressed. No history, no search, no export. It is sent with instructions not to keep a copy.
• The radio room is a role of its own, given only by the organization's platform manager. It needs two-step sign-in and a named account, and opens the board and nothing else. A holder who has not set up two-step sign-in is not sent curfew alerts. It can note that it reached somebody and mark somebody back, but not change curfew. Security and the Director can bring curfew forward for one night, earlier only; the reason is encrypted and shown only to them. While a Security Manager or a Director is away, the colleague named to stand in for them sees and uses the board as a Security Manager would.
• Teams on missions: where the area has a curfew, one row per team of a mission under way: the reference code, the people on it and their phone numbers, where it is heading (the next place marked safe at curfew, or the destination) and when it is expected. Where location sharing is on, the age of the team's last trusted position and where it was, in words such as “near Km 12 bridge” (within 3 km of one of the area's places) or “about 12 km from X”. Never a point, a trail, coordinates or a map, and nothing recorded beyond the positions the mission already keeps. Not the mission's purpose, route, risks or incidents. Security and the Director can open the mission from its row; the radio room cannot.
• In for the night: a team counts as in when it arrives at a place Security has marked safe at curfew, arrives in a risk zone or colour marked “no curfew here”, finishes the mission, is noted safe by the radio room, or presses “We're in for the night” (whoever records the check-ins, undo kept as a line). A position can only ever count a team in, never out. Each step of the chase and each of these is a line in the mission's sealed history, kept as long as the mission. A line holds what happened and when, never typed words. The optional words with “We're in for the night”, and the radio room's notes on a team, are encrypted, shown on the board and deleted after 90 days.
• Written down: each opening of the board (once per quarter hour) and each call made from it, in the log of who looked at what.
• Once entries are deleted, the Director sees only monthly counts per area, with any number under 3 shown as “fewer than 3”.

Every decision on a mission is an entry in its history: who made it, in which job title, and when. That history is what the authorization record prints, and it cannot be edited afterwards.

That is not only a rule in the app. Each history line, check-in and route change on a mission, and each save and comment on an incident report, is sealed as it is written: a fingerprint of the entry, chained to the one before it and signed with a key the database does not hold. The authorization record and the incident report print the chain's final fingerprint, and a “Check this record” button recomputes the chain on demand. A line changed, removed or added outside the app afterwards, by anyone, is named. The database itself also refuses to update or delete those rows.

Going-out entries are deliberately not part of this sealed history. A sealed line can never be deleted, and a record of somebody's evening must be. They are kept on their own, on their own clock (below).

Separately, the platform keeps a log of who opened a mission, a person's profile, an incident, a location trail or the radio room's board, and when, and of each call made from that board. It records that a page was opened, not what was concluded from it. It exists so that misuse can be found afterwards, and it is kept for a year by default. Members are told it exists, on the privacy notice.

• Location trails: 30 days.
• The log of who looked at what: one year.
• Incident reports: seven years.
• Help alerts: the positions, 30 days; the record of who pressed, when and what it turned out to be, seven years. An alert an incident report was written from is kept as long as the report.
• Going-out entries: 7 days after the person is back (the area can set 1 to 30), or 90 days if the radio room or Security was told they were still out at curfew (30 to 365). An entry is deleted only once it is closed. One nobody closes stays on the board until 48 hours after its back-by time; it is then closed as “not marked back”, and Security (the Security Managers and Directors, and the stand-in of any who is away) gets one message per area naming who was never marked back, whatever the alerts switch says and whether or not the area has a curfew. Nobody is told the person is back. The keep period runs from there; the message is deleted with the entry (7 days by default, 90 if the radio room or Security was told at curfew). Afterwards only the monthly counts remain.
• Curfew messages: deleted with the entry they are about, and never kept longer than 90 days.
• A curfew brought forward for one night (who, when and the encrypted reason): 90 days.
• A going-out entry linked to an incident report (the reporter said it happened while they were out): kept as long as the report. Deleting the person's account keeps its row with the name removed.
• Mission records: seven years.
• Backup copies of the database: 30 days.

Each period is set per area by the organization, within limits the platform enforces. Configuration and the newest risk assessment are never swept.

When an account is deleted, everything personal to it goes: the profile, phone numbers, licences, training certificates, memberships, help alerts, the person's going-out entries with the messages about them, and recorded positions (but a help alert an incident report was written from is kept with the report, its positions included, under a code instead of the name). Past missions, incidents and inspections are kept, because the organization needs them, but the person's name in them is replaced with a code such as “Former member 4NWX”. This is pseudonymisation, not anonymisation: the records keep their internal numbers, so a copy taken before the deletion, such as an export, can still link the code to the person. A name typed into free text is not changed, and where two people in the organization share a name, the records that hold only a name are left for a person to check.

Anything deleted — an account, an area, an organization, or records cleared at the end of the periods above — stays inside the backup copies for up to 30 days, then it is gone. A copy is restored only to recover the service; if that ever happens, every deletion made after the copy was taken is done again.

An area's Director can download that area's records at any time, as a spreadsheet and a data file that can be read without Coccu. Uploaded files are listed but not included, and help alerts, going-out entries, incident photographs and voice notes, and notifications are left out. We provide those on request.

Coccu does not hold an ISO 27001 or SOC 2 certification at present. Everything on this page can be checked against the product, and we will answer a security questionnaire in full, but we would rather you heard the absence from us than found it.

For questions about any of this, or to report a security concern, write to admin@coccu.co. The privacy notice covers the same ground from the point of view of the people the information is about.