Vigia security statement
AI draft for legal review. This is a first draft prepared with AI assistance for 365solutions. It is not legal advice. Every statement here is taken from Vigia's technical design; before publication, the delivery team must confirm that each item is in production (items not yet live are marked planned), and a lawyer must review it. Points to confirm are listed in section 11.
Version 0.1 (draft) · 9 November 2026 · Website footer: Security
1. Our approach
Security companies trust Vigia with their guards' locations, their clients' sites, incident evidence and panic alerts. We design for that: every company's data is kept apart, sensitive details are encrypted twice, every important action is recorded in a trail that cannot be quietly changed, and the safety path keeps working when the network does not.
Our security baseline is the OWASP Application Security Verification Standard (ASVS) level 2 for the web apps and API, and the OWASP Mobile Application Security Verification Standard (MASVS) L1 for the mobile apps. We do not claim certifications we do not hold. [Add certifications only when obtained.]
2. Each company's data is kept apart
- Every company has its own account (a tenant) with its own web address. Every record carries its tenant.
- Isolation is enforced in three layers: in the application on every query; in the database by row-level security, so a query without a tenant returns nothing; and in file storage, where every file path starts with the tenant.
- Each tenant has its own encryption key for sensitive fields, and its own audit chain.
- Automated tests run as one company against another company's data and expect nothing back.
- A company's staff never hold a role in another company. Our own staff hold no role in any company (section 5).
3. Encryption
| Where | How |
|---|---|
| In transit | TLS 1.2 or later on every connection; HTTPS only, with HSTS |
| Database | Encrypted at rest (transparent data encryption) |
| Sensitive fields — ID numbers, duress words, alarm passwords, cash-in-transit values and routes | Encrypted again in the application with AES-256-GCM, under a data key per tenant wrapped by a key held in Azure Key Vault; shown only through an audited reveal with a stated purpose |
| Files (photos, evidence, documents) | Encrypted at rest; no public access; opened only through links valid for 5 minutes, issued after a permission check |
| Field app on the phone | Encrypted local database and files; cash-in-transit instructions removed from the phone when the run closes |
| Backups | Encrypted |
When a company leaves and its data is purged, destroying its key makes its sensitive fields unreadable everywhere, including in backups.
4. Signing in and access control
- Multi-factor authentication for back-office, command-centre and client-administrator users.
- Field users sign in on a company-enrolled phone (device binding) with a PIN; lost or stolen phones can be locked, wiped and signed out remotely.
- Permissions by role, limited to the sites and clients a person works with.
- Viewing a person's location history outside a live event, or revealing a sensitive field, requires a stated purpose and is recorded.
- Rate limits protect sign-in, one-time codes, panic, incident submission and reveals, and each company has its own share so one cannot slow down another.
5. Our staff
- Our staff have no standing access to a company's data.
- Support needs an approved support session: we request it, the company's administrator approves or refuses it, it is limited in scope and time (by default 4 hours, read-only, settings and setup), a banner shows it is active, and it is recorded in the company's audit trail. The administrator can end it at any time.
- Platform work that must cross companies (for example scheduled purges) runs only through reviewed, listed code paths.
6. Audit trail you can verify
- Important actions — approvals, corrections, reveals, exports, suspensions, settings changes — are written to an append-only audit trail in the same transaction as the change. The database refuses edits and deletions of audit entries.
- Entries are hash-chained per company and the chain head is anchored daily in immutable storage, so a changed, missing or rewritten entry is detected.
- A company can export its own chain and recompute it without us.
- Corrections to records are new entries; the original stays.
7. Evidence and files
- Incident and cash-in-transit evidence is kept in a separate storage account with immutability; a legal hold stops deletion for police, court or insurance cases.
- Every upload is checked for its real file type and size, and scanned for malware before anyone other than the uploader can open it. Archives are refused.
8. Hosting and resilience
- Hosted on Microsoft Azure, primary region South Africa North, recovery in South Africa West (planned — confirm at go-live).
- Secrets are kept in Azure Key Vault and reached through managed identities; none are in source code or pipelines.
- Databases can be restored to any point in the last 35 days; backups are geo-redundant; we test restores before the pilot and every quarter.
- Recovery targets for command-centre services: 15 minutes of data and 4 hours to restore.
- The field app works offline for up to 72 hours and sends what it captured when it reconnects; panic does not wait for anything else.
- Logs contain no passwords, tokens, PINs, one-time codes, duress words, cash-in-transit values or precise locations.
9. Testing
- Every change runs dependency and secret scanning, static analysis and automated tests, including tenant-isolation and security-convention tests.
- Automated web vulnerability scans run against the test environment, and mobile release builds are scanned.
- An independent penetration test before production and every year after, covering the API, web apps, field app and sign-in service. (Planned — confirm the first test date.) Customers can ask for a summary of the latest results under confidentiality.
- A go-live access review checks every role against the signed-off role matrix.
10. Report a vulnerability
If you believe you have found a security issue in Vigia, email security@vigia.africa. Please give us reasonable time to fix it before sharing it, do not access or change other people's data, and do not disrupt the service. We will acknowledge your report within [3] business days. [Lawyer: confirm safe-harbour wording under the Cybercrimes Act.]
11. Points for owner and legal review
- Confirm that every statement is true in production on the publication date; remove or mark as planned anything not yet live (South Africa region, penetration test, per-tenant keys, row-level security).
- Whether to publish recovery targets and the 72-hour offline figure.
- Responsible-disclosure safe-harbour wording, given the Cybercrimes Act's offences for unlawful access.
- Security contact email and acknowledgement time.