Security · Compliance

Built for finance teams that take security seriously.

Architectural commitments, not features. How we handle access control, audit logging, data isolation, and operational security for the finance and audit teams that depend on us.

GDPR compliant

Full data subject rights

EU data residency

Hosted in Helsinki, Finland

TLS 1.3 in transit

All traffic encrypted

AES-256 at rest

Customer data encrypted

Architectural commitments

Four commitments we made on day one.

These are not features we ship later. They are decisions baked into how the platform was built and how we operate it.

Multi-layered access control

Permissions are defined as a matrix, not roles alone. Every action is gated independently per resource and per role. There is no "admin who can do everything". Every privileged action is named, logged, and scoped.

·Action-level gating: view, create, modify, delete, restore, redact, each individually permissioned
·Customer-facing access and internal admin access live in separate permission models, with audit logging on both
·Permission matrix is a single source of truth. Drift between policy and enforcement is caught automatically before any change ships
·Optional SSO with Microsoft, Google, or LinkedIn for customer-managed identity

Comprehensive audit logging

Every action records who, what, when, and from where. Logs are queryable end-to-end via a request correlation ID, retained according to a documented policy, and survive organisation deletion.

·Captured per event: actor, target resource, IP address, user-agent, request ID, timestamp
·Authentication events (login, MFA, password change, lockout) and record changes with before/after diffs
·Administrative impersonation is logged as a single batch. Every action taken inside an impersonated session shares one batch identifier, so a reviewer can trace the full intervention
·AI agent actions logged
·Customer organisations have direct access to their own audit trail inside the application
·Documented retention policy with a GDPR pseudonymisation path. Logs survive organisation hard-deletion

Architectural data isolation

Customer data is isolated at three independent layers. This is an architectural decision made on day one, not a configuration option that can be turned off, downgraded, or accidentally bypassed.

·Application-level scoping. Every query is auto-filtered by organisation context derived from the authenticated session
·Immutable tenant linkage. Once a record is created against an organisation, that link cannot be reassigned
·Database-level access policies are defined across the schema, with activation of database-layer enforcement scheduled for Q3 2026 (see Forward Initiatives)
·An automated cross-tenant isolation test suite verifies every change before ship

Operational security

Security is operational, not just architectural. The way our team accesses production matters as much as the controls inside the product.

·Restricted production access. A limited set of named individuals only, MFA required, every access logged
·Time-bound audited support grants. When our team needs access to a customer organisation for support, that access is explicitly scoped, time-limited, and every action is logged inside the customer's own audit trail
·Centralised secret rotation. Credentials, API keys, and signing material are rotated on a documented schedule, and on departure events

Encryption & data residency

In transitTLS 1.3 for all traffic, including service-to-service.
At restAES-256 across primary storage and backups.
RegionCustomer data resides in the European Union. Primary hosting in Helsinki, Finland.
BackupsEncrypted, region-locked, retained per documented policy.

AI governance

ScopeAI assists with extraction, IBR drafting, and explanation. The calculation engine handles all calculations.
RedactionStructured payment identifiers (IBAN, payment-card numbers, email addresses, international-format phone numbers) are redacted before prompts leave our infrastructure. Other personal data is governed by our Data Processing Agreement.
TrainingCustomer data is never used to train AI models.
RetentionDocument content is processed by our AI provider and deleted within 24 hours of session completion.
ReviewAI proposals route through an approval queue. Nothing is finalised without explicit user action.

Sub-processors

We use a small set of vetted sub-processors to operate the service. Every sub-processor is contractually bound to handle customer data per our DPA.

Provider	Purpose	Region
EU cloud infrastructure Compute, storage, networking	Compute, storage, networking	Helsinki, Finland
Cloudflare DNS, WAF, edge protection	DNS, WAF, edge protection	Global edge
Anthropic AI processing	AI processing	Contractual EU data handling
Stripe Payment processing	Payment processing	EU + US
Resend Transactional email	Transactional email	EU
Microsoft, Google, LinkedIn Optional SSO providers (customer-enabled)	Optional SSO providers (customer-enabled)	Per provider

Customers are notified of material changes to this list. See our DPA for full terms.

Vulnerability disclosure

Found a security issue? Email a clear description, reproduction steps, and any relevant context to support@leaseaccounting.app.

Scope: Reports about production zentreasury.com and leaseaccounting.app are in scope; staging environments and third-party services are not. Please do not perform social-engineering tests against staff or customers.

For other security questions, the same address works: support@leaseaccounting.app.

Recent security investments

Shipped recently

Per-organisation IP allowlist enforcement

Structured PII redaction in AI prompts

End-to-end request correlation across HTTP, queue, and AI calls

Forward initiatives

What's next

We invest in security continuously. Initiatives currently in progress, with target windows.

Q3 2026

Continued isolation hardening

Q3 2026

Audit log replication

Q4 2026

Expanded role and team scoping

Last updated: 30 April 2026