Question 1

Can you guarantee we will not be hacked?

Accepted Answer

No, and neither can anyone else — any supplier who promises it is selling you something. Security is risk reduction: raising the cost of an attack, removing the easy openings, and making sure you detect and recover when something does get through. What we can commit to is that the common paths into a system like yours are closed, documented, and retested after each change.

Question 2

Do you hold ISO 27001 or SOC 2 certification?

Accepted Answer

No. We hold no such certificate, we are not a certification body, and we will not describe our processes as certified or aligned in a way that implies one. What we do is help you prepare: gap assessment against the framework, implementing the technical controls, and producing the evidence an assessor will ask for. The audit and the certificate come from an accredited third party, and that separation is the point.

Question 3

What does your penetration testing actually cover?

Accepted Answer

We test at application level: web applications, APIs and mobile clients, both unauthenticated and across user roles, looking for injection, broken access control between accounts, session and authentication weaknesses, insecure file handling and misconfigured cloud storage. We do not sell red-team engagements, physical intrusion, social-engineering campaigns or industrial control system testing. For regulated scopes such as a formal PCI DSS test, an accredited specialist should do the work and we will help you scope and brief them.

Question 4

We already have SSL. Is that not enough?

Accepted Answer

A valid certificate encrypts traffic between the browser and the server, which is necessary and no longer distinguishing — it says nothing about whether one logged-in customer can read another's orders. Most incidents we see happen over perfectly valid HTTPS: weak admin passwords, an outdated plugin, an API endpoint that never checks who is asking. Treat the certificate as a floor, not a security posture.

Question 5

Will testing break our production site?

Accepted Answer

We work against staging with production-like data wherever one exists, precisely so that aggressive checks carry no business risk. When testing must touch production, we agree the window, the rate limits and the specific checks in writing first, and anything potentially destructive is either excluded or run under supervision. We would rather report a slightly narrower result than take your checkout down to prove a point.

Question 6

What do we receive at the end of an engagement?

Accepted Answer

A findings report with reproducible evidence and honest severities, a prioritised remediation plan written as engineering tickets your team can pick up, a short summary for non-technical stakeholders, and a retest confirming what was closed. Where compliance work is in scope you also get the control documentation and the register of gaps still open, with owners against each one.

Question 7

Who signs off that we are compliant with GDPR or KVKK?

Accepted Answer

Your legal counsel or data protection officer does, never us. We run the technical side — data mapping, retention, access control, encryption, logging, processor agreements at a technical level, and a gap list with remediation steps — and hand over documentation your lawyers can rely on. Compliance is a legal determination about your business, and any agency that claims to certify it is overreaching. That work is detailed on our GDPR Compliance & Data Privacy page.

Question 8

How often should we test?

Accepted Answer

Once a year is a reasonable baseline for a stable site, but the more useful trigger is change: a significant release, a new payment or login flow, a platform migration, or a new integration with access to customer data. Continuous checks matter more than the annual event — dependency and secret scanning in CI catch a large share of what would otherwise be found months later.

Question 9

What is the realistic threat to an online store like ours?

Accepted Answer

Almost never a targeted attacker. It is automated: credential stuffing against your login with passwords leaked elsewhere, bots probing for known vulnerabilities in outdated plugins and packages, card testing against your checkout, and phishing aimed at whoever holds the admin account. That shapes the priorities — MFA on admin accounts, rate limiting, patching discipline and monitoring beat exotic defences for this profile.

Question 10

What about ransomware and backups?

Accepted Answer

Backup is the control that decides whether ransomware is a disaster or an outage, and it only counts if you have restored from it. We check that backups exist for every system that matters, that at least one copy is isolated from the credentials that could delete it, that retention covers the time it typically takes to notice a compromise, and that a restore has been performed end to end with the duration recorded.

Question 11

Where do the more specialised areas sit?

Accepted Answer

This page is the overview; the depth lives in the children. Security Audits & Compliance covers framework-driven reviews and evidence, Cybersecurity Auditing the technical audit of systems and configuration, Penetration Testing the hands-on application testing, Identity & Access Management single sign-on, roles and MFA, and GDPR Compliance & Data Privacy the data protection work. Most engagements start with an audit and pick up from there.

How can we help?

Cybersecurity
FAQ

Helpful
information

Getting Started

Timeline

Pricing

Support

Still have questions?

CybersecurityFAQ

Helpfulinformation