Service
Cyber security and audit
Security is not a product — it is a chain that needs continuous maintenance. The weakest link is usually found in configuration, not in code.
What a website security audit covers
We work only on systems we are authorised for, under written permission.
Application security audit
Authorisation flaws, injection, session management, file upload handling and API security are reviewed.
Penetration testing
Testing from an attacker’s perspective, under written scope and permission. Findings are ranked and each comes with a fix.
Server hardening
Firewall, SSH policy, TLS configuration, disabling unnecessary services, and a working update routine.
Secrets and access management
Removing keys written into code, moving them to environment variables, and making every access individually attributable.
Backup and restore rehearsal
Taking backups is not enough; if a restore has never been tested, assume there is no backup. We rehearse it and time it.
Post-incident response
Clean-up after an attack, closing the entry point, reviewing logs, and the measures that stop a repeat.
Why the source code stays with us
The approach on this page leads directly to our answer to a frequent question: we do not hand over project source code. The reason is technical, not commercial.
The code of a running system is inseparable from its database credentials, payment and API keys, session secrets and infrastructure configuration. Every additional copy widens the attack surface: one copy on a personal laptop, on a former employee’s drive, or in a repository accidentally left public is enough to open the whole system. A significant share of the breaches that reach the news start exactly there.
Keeping the code in a single controlled environment is also what makes it possible to apply security patches without waiting for you to ask. When copies are scattered, nobody can say which one was updated when a vulnerability is fixed.
In return, everything that is yours stays yours and is handed over on request: all of your data (exported in standard formats), your domain, DNS and email accounts, your content and images, your logo and design source files. Accounts are opened in your name and we are only an authorised user. You are never left dependent on us — dependency comes from who holds the data and the accounts, not from who holds the code.
The flaws we find most often
The same five headings come back audit after audit.
- Authorisation enforced only in the interface. The button is hidden but the endpoint is still open to everyone. The most common and most dangerous mistake.
- Keys sitting in the code. A database password or API key in the repository. Once committed it lives in history — deleting is not enough, the key must be rotated.
- Unpatched components. Library versions with known vulnerabilities. Attackers do not know you; their scanners know your version number.
- Unchecked file uploads. File type read from the client instead of verified against the content signature.
- Backups exist, restores were never rehearsed. A restore attempted for the first time during a crisis usually fails.
Frequently asked
What do you need to run a penetration test?
Written permission and a clear scope: which domains, which IP addresses and which accounts are in scope; during which hours; and which techniques are excluded (for example anything that could cause downtime). No test starts without an authorisation document — that is both a legal requirement and a professional boundary.
What do we get at the end of an audit?
A report with findings ranked by severity: for each one, where it is, how it was verified and how to close it. The executive summary is kept separate from the technical detail. We can apply the fixes ourselves, or your team can — the report carries enough detail for that.
What do we need for GDPR and KVKK?
On the technical side both regimes expect similar things: access limited by role, encryption in transit and at rest, logging, a defined retention period and deletion mechanism, and monitoring that makes breach detection possible. We build and document the technical measures; the legal documents (privacy notices, consent records, processor agreements) need your lawyer. Be wary of proposals that blur this line.
Our site was hacked — can you help?
Yes. The order matters: first stop the spread, then find how they got in, then clean up. Reversing that order means they return through the same door. Afterwards all passwords and keys are rotated, logs are reviewed, and the preventive measures are written down. In an emergency, calling is fastest.
Is your report valid for regulated audits?
No — and we say so up front. In Türkiye, for a penetration test report to be formally accepted in BDDK, BTK, KVKK or public-sector audits, the testing firm is expected to hold a TSE TS 13638 Class A penetration testing authorisation. We do not hold it. What we do is a technical security audit: finding vulnerabilities, verifying them and closing them. If regulation requires a certified report, we point you to the right place — and we can then do the remediation work on the findings. Be equally careful of offers that sell the certificate but deliver only an automated vulnerability scan; those are not the same thing.
Is security a one-off job?
No. An audit shows the state on that day. New component versions, newly disclosed vulnerabilities and your own changes keep moving the picture. That is why security runs as part of continuous maintenance: an update routine, backup rehearsals and periodic review.
Let us audit your setup
We will look at your current system from the outside. Critical findings go first, the rest is queued in order of risk.