# Security-aware architecture

> Access control, data isolation and secure defaults designed into the architecture — in the data model, the file storage and the server, not added after launch.

Canonical: https://www.deusengineering.com/en/services/security-architecture · Language: en · Last updated: 2026-10-19

Review & continuity · [Services](https://www.deusengineering.com/en/services)

Security-aware architecture means deciding, while the system is being designed, who can see and change which data and where each rule is enforced — in the data model, the file storage and the server — rather than adding those rules after launch.

It matters most for software that holds client, financial or personal data, serves several organisations from one database, or shows different roles different things. Reviewing a system you already run is a separate service: technical audit & architecture consulting.

Outcome: Security decisions made deliberately — and written down.

## Typical needs

- Sensitive client, financial or personal data
- Roles that must see different things
- Several companies or offices whose data must stay apart

## What you receive

- Role-based access and data isolation designed into the data model
- Secure defaults: HTTPS, security headers, secrets kept on the server
- Private file storage without public links, with access checked on every download

## How the work runs.

1. Map access first: Before the database schema is written, list who uses the system, which organisation each record belongs to and which fields are sensitive — and agree who may see, change and delete what.
2. Enforce it in the database: Row Level Security policies check every row against the user’s organisation and role, so the rules hold even when the database is reached outside the app.
3. Keep files and keys private: Documents go to private storage without public links and are served only after a server-side check. API keys and other secrets stay on the server and never reach the browser.
4. Secure defaults on every change: Every response is served over HTTPS with HSTS and security headers, and CI scans dependencies and secrets, so the defaults stay in place as the code changes.

## Technologies

- PostgreSQL Row Level Security
- HTTPS, HSTS & security headers
- Dependency & secret scanning

## In practice

Pametni Advokat: office isolation in the database, private documents without public links, and downloads only after account, office and role checks.

[Pametni Advokat](https://www.deusengineering.com/en/work/pametni-advokat)

The engineer who does this work is the founder, Filip Volf — you work with him directly. [About](https://www.deusengineering.com/en/about#founder)

## About this service.

### How is this different from technical audit & architecture consulting?

A technical audit produces a written review of a system that already exists: findings, priorities and trade-offs. This service designs and builds the controls themselves — access rules, data isolation, private storage and secure defaults — into a new system or into the part of an existing one being rebuilt. An audit can come first and show where to start.

### Can you promise our application will be secure?

Nobody can honestly promise absolute security. What you get is specific controls, each stated precisely: who can reach which data, where that is enforced, how files are served and which secrets stay on the server — and anything not yet in place is called a plan.

### What happens when someone leaves or changes role?

Access is tied to each person’s own account and role and checked in the database itself, so deactivating the account or changing the role changes access with it — there is no shared password or link left to revoke. In Pametni Advokat every user has a personal sign-in, a deactivated account loses access immediately, and deleting records is reserved for the lawyer.

## Related services

- [Technical audit & architecture consulting](https://www.deusengineering.com/en/services/technical-audit-consulting): A written review of a system you run or a decision ahead — architecture, data model, code, dependencies, security and operations — with findings in priority order.
- [APIs, backend architecture & PostgreSQL](https://www.deusengineering.com/en/services/api-backend-postgresql): Data models, APIs and server-side logic that keep business rules in one place — with PostgreSQL doing the work it is good at.
- [Cloud infrastructure & integrations](https://www.deusengineering.com/en/services/cloud-infrastructure-integrations): Deployments, CI/CD, email, storage and third-party APIs wired together so releases are routine and integrations fail loudly, not silently.

## Let’s talk about what you’re building.

Describe what you need built or fixed, how the work runs today and the constraints. You get clarifying questions or a first outline of the approach — by email, in English or Serbian.

Or write directly: contact@deusengineering.com · [Contact](https://www.deusengineering.com/en/contact)