Security

Trust centre

Last reviewed 19 October 2026. Everything below is self-assessed, not certified: it describes what the software does today, and the list at the end says what is not done yet.

Praescius tells organisations what is happening near their people and sites, sends approved instructions and records who is safe. That only works if the record can be trusted. This page describes the controls that make it so, in plain words, without claims beyond what the code does.

1. Each organisation kept apart

• In the database, not only in the application. Every table that holds an organisation's records uses PostgreSQL row-level security. The organisation is set for each database transaction, and the role the application connects with is not a superuser, so it cannot bypass the rules even if application code is wrong.
• Public pages show status only. The public website shows each region's status. Findings, people, sites and messages stay behind sign-in.

2. Access and sign-in

• Two-step sign-in for every console user. Console users enrol an authenticator app (TOTP) at their first sign-in. An organisation using Google sign-in may instead rely on its identity provider's own two-step check; its administrator turns that on. Employees use the app or one-time check-in links and do not see the console.
• Passwords. Stored only as Argon2id hashes. Repeated failed sign-ins lock the account for a while.
• Permissions checked on the server. Each role has a set of capabilities, read from the database on every request. Nothing a browser sends can widen them. An administrator's "preview as another role" is read only.
• Browser protection. The console runs scripts only from its own address (a Content Security Policy with no inline scripts), session cookies are HTTP-only and same-site, and every signed-in change must carry the console's own client header.
• Praescius support access. Our support staff can look at an organisation only with a written reason and for a fixed time of up to eight hours. The view is read only in the database itself, appears as a banner, and is recorded in the organisation's own audit log. Each organisation chooses whether a visit needs its approval first.

3. Two people for anything that goes out

• Separation of duties. Findings, assessments, outlooks, analytic editions and instructions to staff are approved by someone other than the person who drafted them. Sending an instruction needs a separate dispatch permission: a chief of security approves but does not send, and Praescius's platform owner can never send.

4. A record that stands up

• Tamper-evident audit log. Sign-ins, approvals, sends, answers, downloads and permission changes are written to an audit log that the database refuses to change or delete. Each entry carries the hash of the one before it, so a changed or removed entry breaks the chain. Auditors can verify their organisation's whole chain from the console at any time, and every run is itself recorded.
• Evidence packs. For any incident or instruction an authorised person can export one pack, as HTML, PDF and JSON: what was known when (findings, sources and their grades, timestamps), who drafted, approved and sent what, who was told on which channel, and who answered and when, with Safe, Needs help, Not affected, Unknown and No response kept apart. It ends with a verification section: the audit entries and their chain links, the state of the chain when the pack was made, and the SHA-256 of the pack, which is also written into the audit log. Anyone holding the file can check it was not altered. Making and downloading a pack are recorded; people are named only for roles that may see check-ins.
• Nothing is overwritten. Published reports, issued analytic editions and evidence packs are kept as versions. The database refuses changes to them.

5. Encryption and hosting

• Encryption in transit. The website, console and API are served over HTTPS, and the self-hosted kit sends a Strict-Transport-Security header. The application's connection to the database requires TLS.
• At rest. The managed database and hosting providers listed below encrypt their storage; this is their control, not something Praescius's own code adds.

6. Where data lives, who processes it, how long it is kept

• Data residency. Each organisation has a residency setting, which its administrator confirms during setup. On the shared service, records are stored in the European Union (Frankfurt). A customer that needs another country, for example a government, agrees a dedicated deployment there; choosing another country in setup records a request, and nothing moves without that agreement.

Sub-processors

The privacy notice has the full list with regions. Customers are told before a sub-processor that handles their people's information is added or replaced.

Retention

• Locations shared during an incident are cleared 30 days after the organisation's last incident closes.
• Contact-form requests are deleted 24 months after they were sent.
• Raw material collected from public sources is cut back after each source's retention period; its hash and title stay, so findings can still be checked.
• The audit log and evidence packs are kept for the life of the contract, as the privacy notice describes.

7. Responsible use

• No attack prediction. Outlooks give region or airport likelihoods of a defined set of outcomes only. Praescius never gives the time, hour, place, facility or target of an attack: no countdowns, no blast rings, no target lists. The software refuses outlook wording that tries to.
• Hostile groups. Their statements appear only as attributed summaries from official or reputable sources. Their own channels and media are never linked or embedded, not even in an evidence pack.
• About events, not private individuals. Collection covers official warnings, aviation, weather and news about events and places. The terms forbid using Praescius to watch or target private individuals.

8. Security incidents

• A written runbook. We contain the problem, work out which organisations and people are affected, tell affected customers without undue delay, and keep the evidence. A broken audit chain is handled as a security incident.
• Report a vulnerability to security@praescius.si. Please give us time to fix it before telling anyone else; we will tell you what we did.

9. Not done yet

• No independent penetration test has been done yet.
• No SOC 2 report and no ISO 27001 certificate yet. Our questionnaire answers are mapped to those frameworks but are self-assessed.
• No customer-managed encryption keys, and no SAML single sign-on or SCIM provisioning yet.
• The contracts and policies below are drafts for legal review.

10. Documents

Ask your Praescius contact, or write to security@praescius.si, for any of these. Each is a draft for legal review.

• Security questionnaire answers, mapped to ISO 27001 Annex A and the SOC 2 trust services criteria (self-assessed, not certified).
• Data processing agreement.
• Data protection impact assessment (DPIA) template for customers.
• Incident response runbook.
• SOC 2 readiness checklist: what is done and what is missing.

See also the privacy notice and the terms of service.