Security Overview
At faktoora, security is the foundation of everything we build. As an e-invoicing platform for sensitive financial data, we protect your data at every level – from the infrastructure and the application to our internal processes.
Our Security Principles
| Principle | How we implement it |
|---|---|
| Confidentiality | Strict access restrictions, encryption of external communication and of stored data, hosting in Germany |
| Integrity | Parameterised database queries, tamper-evident audit trail, integrity verification of backups |
| Availability | Frequent encrypted backups at a separate location, automatic recovery of services, a documented and tested disaster recovery plan |
| Least privilege | Role-based access control, services with minimal privileges, restricted production access |
| Defence in depth | Multiple security layers across network, infrastructure, application and data |
| Controlled changes | Code changes go through merge requests with automated quality checks; production deployments are carried out manually by authorised personnel |
| Secure by default | Hardened base images, protected branches, services without root privileges |
Encryption
In Transit
External communication is encrypted with TLS 1.2 or higher, including API calls, webhook deliveries, e-invoice delivery and third-party integrations. Emails are transmitted via TLS where the receiving server supports it.
At Rest
Our production servers use full disk encryption for databases and file storage, and our backups are encrypted. Access to the keys is restricted to a small number of explicitly authorised persons.
At Application Level
Login is handled by our self-operated identity provider – the faktoora application itself does not store any passwords. API keys are stored only as a one-way hash and cannot be retrieved after creation. Sensitive credentials for integrations are encrypted before they are stored. Audit log entries are cryptographically chained, so that subsequent changes can be detected.
Access Control
Application Access
faktoora supports several authentication methods:
- Email and password via our identity provider, with brute-force protection and support for two-factor authentication
- Single sign-on (SSO) via OpenID Connect for business customers
- API keys for programmatic integrations, stored in hashed form and with a mandatory expiry of at most one year
Our permission model uses role-based access control with fine-grained permissions, tenant-scoped access for accounts with multiple companies and plan-dependent feature enablement.
Support Access
When you contact support, authorised faktoora personnel may temporarily access your account in order to investigate and resolve the issue. This access is restricted to authorised personnel, time-limited and recorded in the tamper-evident audit trail. For business customers, it takes place only within the scope of the data processing agreement and the AGB (clause 8.11) – to handle a customer request, for error analysis or to provide the agreed service.
Production Infrastructure
Production access is restricted to explicitly authorised personnel and requires multi-factor authentication. The production environment is isolated from all development systems – no CI/CD pipeline and no development system can reach it. Deployments are carried out exclusively manually by authorised persons.
Access Lifecycle
- New team members receive role-appropriate access; production access requires approval by technical management
- Quarterly review of access to code repositories and production
- On departure, access is revoked promptly and shared credentials known to the person are rotated
Secure Development Process
Code changes follow a structured process:
- Traceable changes – changes are linked to documented requirements and acceptance criteria
- Branch isolation – work is developed in separate branches and merged via merge requests into protected branches that only authorised maintainers may merge
- Automated quality checks – every merge request goes through linting, type checking, automated tests and build verification; as long as these fail, merging is not possible
- Automated security scans – static code analysis and vulnerability scans of dependencies run automatically in our build pipelines; findings are assessed and handled on a risk basis
- In-depth review – extensive or higher-risk changes are reviewed in depth by a second developer where needed, including manual testing
- Staged rollout – changes pass through staging environments before they go into production
Supply Chain Security
Where available, our application services are based on hardened, minimal base images. Their origin and signature are cryptographically verified before every build, and each verified base image comes with a software bill of materials (SBOM). All services run without root privileges.
Dependency Management
Third-party dependencies are continuously monitored for known vulnerabilities. In our projects, newly published package versions are adopted only after a waiting period – as protection against compromised releases.
Infrastructure Security
Hosting
All production systems are operated in ISO 27001 certified data centres in Germany.
Separation of Environments
Development, test and production environments are strictly separated. Production is isolated and cannot be reached from any other environment.
Network Security
Our infrastructure uses several layers of network protection, including firewalls at provider and host level as well as authentication at application level. Data stores are never directly reachable from the internet. Administrative access to the production servers requires multi-factor authentication.
Error Monitoring
The application's error monitoring runs on our own infrastructure in Germany. Error reports are minimised on the client side before they are transmitted.
Audit Logging
User actions are recorded in an append-only audit trail. Each entry is cryptographically chained to the previous one, so that subsequent changes can be detected.
Secrets Management
Production secrets are provided to the services at runtime, are not accessible from development and test environments, and access to them is restricted to authorised personnel.
Questions?
For security questions, please contact security@faktoora.com.
To report a vulnerability, please visit our Vulnerability Disclosure page.