Security and Incident Notice

Security and Incident Notice

Univia Tax — UAE Tax Compliance & Business Records

Effective date: 4 August 2026 · Last updated: 19 Jul 2026

This document describes Univia Tax's security posture honestly, including what is not yet in place. It is written that way deliberately: a customer trusting us with their tax records deserves an accurate picture rather than a reassuring one.

1. Our commitment

We will not describe a control as being in force when it is not. Where a protection is partial, configuration-dependent, or planned, we say so. Where we know of a residual risk, we publish it (clause 4).

2. What is in place

2.1 Data in transit and at rest

• HTTPS is enforced throughout. HTTP Strict Transport Security is applied for two years, including subdomains.

• Data is encrypted at rest by our database and object storage providers.

• Passwords are stored only as bcrypt hashes. We never hold a password in readable form, and we cannot recover one for you.

• We never store payment card numbers or bank details. Card data goes directly to our payment processor.

2.2 Authentication and sessions

• Authentication is enforced by middleware across every application route, not only at the page level. An automated test prevents the route list and the protection matcher from drifting apart.

• Sessions are capped at 14 days, after which re-authentication is required.

• Session cookies are marked Secure in production and use hardened __Secure- / __Host- cookie prefixes.

• Sign-in supports email and password, or Google OAuth.

2.3 Tenant isolation — the honest position

Univia Tax is multi-tenant. Keeping your data separate from every other customer's is the single most important control in the system, and it is enforced at three layers:

1. Schema. Ownership columns are non-nullable on records tables, with restricted deletion.

2. Query layer. Every accessor takes the acting user and resolves through the ownership chain. This is the primary enforcement today.

3. Tests. A cross-tenant isolation test suite is mandatory in the same change that creates a data table. A change adding a table without its isolation suite fails review by definition.

In addition, PostgreSQL row-level security policies are deployed and forced across all 38 application tables, keyed to the acting user, and proven against a real PostgreSQL engine in automated tests — including that raw SQL under one user's tenant context cannot read or write another user's data.

The limitation, stated honestly: database-level enforcement is active on a subset of routes today and is being extended across the remainder. On the other routes, isolation is enforced at the query layer and by the mandatory automated test suite. The precise route-level position, and the plan to complete it, are recorded in the internal Security Hardening Register and are available to enterprise customers under NDA in the Enterprise Security Pack. [DISCLOSURE DECISION — 20 Jul 2026: route-level detail moved out of the public notice; see clause 4 for the disclosure tiers.]

2.4 File uploads

• Files go directly from your browser to object storage using short-lived presigned URLs. They never pass through our application server.

• Uploaded documents are stored in AWS me-central-1 (UAE).

• A 25 MB size cap applies, and only PDF, Excel, CSV, PNG, JPEG, and WebP files are accepted.

• Content verification: before any processing, the leading bytes of every file are checked against its declared type. A renamed executable, or any file whose contents contradict its extension, is rejected, the document is failed with a plain-English reason, and an audit event is written.

• Malware scanning: the Service supports a pluggable scanning service. Where none is configured, every document is recorded as "not scanned" and processed anyway — and the document list shows that status on every row. The Service never claims a scan that did not happen. Note that content verification rejects renamed executables but does not detect malicious content inside a well-formed PDF or spreadsheet. [OPERATIONAL DECISION PENDING — select and enable a scanning service, or accept and disclose "not scanned" at launch.]

2.5 Application hardening

• An enforced Content Security Policy (not report-only): default sources restricted to our own origin, framing denied, object sources blocked, base URI and form actions restricted, insecure requests upgraded, and no external script host permitted at all.

• X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, X-Frame-Options: DENY, and a restrictive Permissions-Policy.

• Rate limiting on login (10 per 15 minutes per IP), registration (5 per 15 minutes per IP), upload presign (30 per minute per user), document confirmation (60 per minute per user), chat (20 per minute per user), import commit (10 per 10 minutes per user), and e-invoicing sandbox submission (10 per minute per user). Refusals return a clear message and a retry indication.

2.6 Integrity and traceability

• An audit trail records the acting user, the company, the entity affected, the action, associated metadata, and the timestamp.

• An amendment trail on records: every change writes the original value, the new value, the user, the timestamp, and the reason.

• Records included in a signed-off return become immutable. Corrections are made by issuing a new, linked record — never by editing history.

• Every computed figure carries its inputs, method, result, assumptions, and legal citation. This is a security property as much as a professional one: an output cannot be silently changed without the working contradicting it.

2.7 Backup and recovery

• Our database provider offers point-in-time recovery from write-ahead log history, and a documented restore-to-branch runbook exists.

• Restoration is non-destructive: a restore creates a new branch and the damaged state is preserved for investigation.

• Outstanding: a full restore test has not yet been performed, and the provider's history retention window must be confirmed at seven days or more. Both are required before launch. [OPERATIONAL — see docs/security/HARDENING.md §5.]

2.8 Internal access

Access to customer data by Univia personnel and contractors is limited, purpose-bound, logged, and governed by docs/legal/employee-and-contractor-access-terms.md.

2.9 Development practice

• Secrets are held in environment configuration and are never committed to source control.

• The payment integration is configured to refuse live-mode credentials until deliberately promoted.

• Cross-tenant isolation tests, the tax-claim and legal-claim review lanes, and the regulatory copy-guard all run in the build and fail it on breach.

3. What we do not yet have

Stated plainly, because a security questionnaire will ask:

• No third-party security certification or attestation. There is no ISO 27001 certificate, no SOC 2 report, and no independent penetration test report. ISO 27001 readiness work exists internally and is incomplete. Do not represent otherwise.

• No formal 24/7 security operations centre or on-call rotation. [CONFIRM current arrangement.]

• No bug bounty programme. Responsible disclosure is welcomed under clause 6, but is unpaid.

• No customer-configurable data residency. Documents are stored in the UAE; other processing is where our providers operate.

• No single sign-on (SSO/SAML) or enforced multi-factor authentication. [PRODUCT FOLLOW-UP — both will be asked for by firm and enterprise customers.]

• No self-service account deletion. Deletion is handled manually on request.

4. Known residual risks — and how we disclose them

Security disclosure operates in three tiers. [DISCLOSURE DECISION — 20 Jul 2026: the previously itemised public list of technical weaknesses is replaced by this summary. Publishing exact weaknesses hands an attacker a map, turns temporary engineering states into standing contractual representations, and makes this notice inaccurate on every code change. The itemised record is preserved internally.]

• This public notice states verified controls and the honest high-level limits of them.

• The Enterprise Security Pack, available to customers and diligence counterparties under NDA, describes controls, residual risks, and remediation plans in detail.

• The internal Security Hardening Register (docs/security/HARDENING.md) records exact open items, affected paths, and remediation status. It is not published.

At the date of this notice, the register's open items fall in these areas: completing database-level tenant enforcement across all routes (clause 2.3); production configuration of shared rate limiting; content-security-policy hardening; malware scanning enablement (clause 2.4); background-worker database privileges; narrowing the outbound connection policy; and completing the backup restore test (clause 2.7). Nothing is concealed from a customer who asks: request the Enterprise Security Pack.

5. If there is an incident

5.1 What we will do

• Contain and investigate without delay, and preserve evidence.

• Notify affected customers without undue delay, and within 72 hours of becoming aware of a personal data breach affecting their data.

• Tell you what we know, including what happened, what data was affected, what the likely consequences are, what we have done, and what you should do — in phases if the full picture is not yet available, rather than waiting for certainty.

• Support your regulatory notifications. Where Univia is your processor, notifying the UAE Data Office and affected data subjects is your responsibility as controller; we will give you the information and assistance you need.

• Publish a post-incident summary for any incident with material customer impact, once containment is complete.

• Not quietly amend this document to make a control look better after the fact. Changes are dated.

Contractual detail is in clause 10 of the Data Processing Addendum.

5.2 What we ask of you

• Keep your account contact email current — it is how we reach you.

• Report suspected account compromise immediately to support@univiaglobal.com .

• Do not share accounts between people.

6. Responsible disclosure

If you have found a security vulnerability in Univia Tax, please tell us.

Contact: support@univiaglobal.com [CONSIDER — a security.txt file and a PGP key.]

Please do: report privately and give us reasonable time to fix it before disclosing; include enough detail to reproduce; test only against your own account and data.

Please do not: access, modify, or exfiltrate another customer's data; run denial-of-service, spam, or social-engineering tests; or use an automated scanner against production without asking first.

Our undertaking: we will acknowledge your report within [RESPONSE TARGET — 5 business days proposed], keep you informed, credit you if you wish, and not pursue legal action against a researcher acting in good faith within this process. There is no bounty at present.

7. Changes

This document is updated whenever the underlying posture changes. The date at the top is the date of the position described. If a control listed here is later withdrawn, this document will say so rather than go quiet.

Security questions from prospective customers: support@univiaglobal.com .