Application and data security audits.

Only named accounts with SSH keys and MFA. Production access is limited to two named people, and everyone else works in the test environment. Accounts expire on the day the engagement ends. We keep secrets and .env files only in a password manager, with per-project access, outside the repository and messaging apps. We rotate keys after every change in the team.

In data centers within the EEA—Warsaw or Frankfurt. Server disks are encrypted, and traffic runs over TLS 1.2/1.3 with HSTS enforced. We encrypt backups before sending them to remote storage and keep their keys off the server they belong to. On request, we send you the list of subprocessors by name.

A full backup once a day, an incremental backup every hour, 30-day retention. Once a quarter, we restore a backup on a clean server and measure the restore time, because only a backup that has actually been restored proves it will work after a failure. We keep logs for 90 days, free of passwords, tokens and national ID numbers: we filter by field name before anything is written to disk.

Only in anonymized form. Before taking a dump, we run a script that anonymizes email addresses, phone numbers, ID document numbers and payment data, and the script stays in your repository. Production, staging and local environments each have their own databases, keys and email accounts. Staging sends no email to external addresses.

Every pull request is reviewed by a second person—nobody ships their own code to production unreviewed. CI runs tests, a static analyzer and a dependency scan (composer audit, npm audit). We update dependencies every month and patch vulnerabilities rated CVSS 9.0 or higher within 72 hours, weekends included.

Before each deployment, we take a database dump and tag the release. Rolling back takes a single command and less than a minute of downtime. Production deployments stop at 3 p.m. CET on Fridays. We connect monitoring to your Slack channel, so you see a 500 error alert in the same minute we do. We respond to critical incidents within 4 business hours.

We notify you of a suspected breach within 24 hours of detection, so you have time to report it to the data protection authority within the 72 hours required by GDPR. You receive the scope and categories of data affected, the time window, the list of systems and a description of what we have already contained. If there has been an intrusion, we secure the logs first, because they show how the attacker got in and let us close that route for good.

We use business tiers of AI tools, where the provider contractually excludes training models on the data we submit. We never paste secrets, .env files or production data into them. If your policy prohibits AI tools entirely, we work without them and confirm this before the project starts.

We treat the scanner as the starting point for a proper review. The most serious flaws sit in the application’s business logic: a server request with no permission check, an ID that can be swapped, browser data accepted at face value. An automated tool misses them because on paper everything works, so we review the code by hand and show you what actually needs fixing.

Because an audit finding is, in practice, a manual for exploiting the vulnerability. Once published, it harms the system owner even after the fix, since the same bug usually sits in several places in the same codebase. That’s why we talk about vulnerability classes, our audit checklist and our own access rules—the same ones we apply to your project.

Yes. The report is yours, and it contains no clauses that would prevent this. Each item includes its location in the code and a description of the fix, so your own team or any contractor can handle it.

Email us before you clean anything up. Untouched files and logs let us determine how the attacker got in and close that route. We secure the current state, find the entry point, remove hidden backdoors and close the vulnerability, so the system returns to stable operation.