Your data protected
Security is considered from the first line of code. Access is restricted by role, sensitive data receives appropriate protection and critical actions can be logged. The exact controls follow from your system's risks, data and management agreements.
Security by design · controls and guarantees only as agreed in scope
What you concretely receive
Not how it works, but what it means for your business.
Separated client data
Authorisation rules and, where appropriate, database policies restrict which data a user or organisation can access.
Encrypted storage
Sensitive data is encrypted in transit and/or at rest where appropriate. Specific controls follow from data classification and the threat model.
Critical actions reviewable
Agreed critical events are logged with suitable retention and access controls, supporting investigation when needed.
Automatic protection
Rate limits, validation and risk-based blocking can restrict suspicious patterns. Monitoring and follow-up remain part of the management agreement.
Privacy by Design
Built according to GDPR principles: data minimisation, encrypted storage and a data processing agreement available. Concrete compliance depends on contractual arrangements and your configuration.
Automatic cleanup
Expired sessions and tokens can be removed according to agreed retention rules. Exceptions and access rights remain part of periodic review.
Five security principles
Five design principles for custom systems. The controls applied depend on the threat model, data and agreed project scope.
Everything coming in is suspicious
No blind trust
Forms, API requests and uploads are treated as untrusted input. Validation and filtering reject input that does not meet agreed rules, reducing attack risk.
Error messages reveal as little as possible
Limited technical detail
Public errors are kept generic while technical details are logged internally. This reduces the information an attacker can obtain from an error response.
The database guards itself
Separated at database level
Where the data model requires it, PostgreSQL Row Level Security can also restrict client data at database level. This adds a control layer alongside application permissions.
Reliable, even under heavy load
Designed and tested for risk
Transactions, idempotency and load behaviour are designed and tested for the application to reduce risks such as duplicate processing and corrupted data.
Deliberately selected, monitored components
Less vulnerable, more control
Dependencies are deliberately limited and monitored with automated checks for known vulnerabilities. Findings are prioritised by risk and maintained within the agreed service.
GDPR & Privacy by Design
For custom work, we use Privacy by Design as a guiding principle. Data protection is considered from the design stage. Specific GDPR compliance and controls depend on contractual arrangements, your configuration and usage; a data processing agreement is available.
- Data minimisation — only store what is necessary
- Appropriate encryption of sensitive data
- Retention and cleanup rules for the agreed data flows
- Data processing agreement available
- Logging of agreed critical events
- Incident and data breach procedure within the management agreement
Under the hood
For developers and technically interested parties:
- Row Level Security where the data model needs additional database isolation
- Appropriate session architecture, such as access and refresh tokens
- API authorisation by identity, role and resource
- Rate limiting against brute-force attacks
Daily protection
Examples selected according to risk and scope:
- Two-factor authentication for administrators
- Automatic cleanup of expired sessions
- Content Security Policy against code injection
- Per-client access control at API level
Controls follow the threat model
Identity, application and database controls
Critical events logged as agreed
Specific controls, test coverage and management arrangements are recorded per project.