Question 1

How do we get started?

Accepted Answer

Reach out through the contact page with a bit of detail on what you're looking to test or assess. We'll follow up to scope the engagement, targets, timeline, and goals, before any work begins.

Question 2

How is an engagement priced?

Accepted Answer

Pricing depends on scope, the size of the environment, depth of testing, and timeline. We provide a fixed quote after an initial scoping conversation, not a generic rate card, since the right price depends on what's actually being tested.

Question 3

Do you sign NDAs / confidentiality agreements?

Accepted Answer

Yes. Confidentiality is standard for every engagement, we're routinely handling sensitive information about your infrastructure and findings, and treat it accordingly.

Question 4

What does a final report look like?

Accepted Answer

Every engagement ends with a written report covering an executive summary, detailed technical findings with reproduction steps, risk ratings tied to business impact, and prioritized remediation guidance. Format varies slightly by service, see each service page for specifics.

Question 5

Can you work with our existing security or engineering team?

Accepted Answer

Yes, most engagements involve some coordination with your internal team, whether that's providing scoping information, reviewing findings together, or handing off remediation work.

Question 6

Do you only work with large enterprises?

Accepted Answer

No. We scope engagements to the environment in front of us, whether that's a small SaaS product or a large multi-tenant enterprise environment.

Question 7

How is this different from a vulnerability scan?

Accepted Answer

Automated scanning identifies known signatures. Our testers manually validate, chain, and exploit weaknesses to prove real-world impact, and surface issues scanners miss, like business logic flaws and chained privilege escalation.

Question 8

Do you offer black-box, grey-box, or white-box testing?

Accepted Answer

Yes. We scope engagements to match the level of access and information appropriate for your goals, from zero-knowledge external testing to fully credentialed internal reviews.

Question 9

Do you map findings to the OWASP Top 10 and MITRE ATT&CK?

Accepted Answer

Yes. Every finding is classified against the OWASP Top 10 (or the relevant CWE for non-web findings), and where applicable, mapped to the specific MITRE ATT&CK tactic and technique it enables, so the report shows both what the flaw is and how it fits into a realistic attack chain.

Question 10

Do you use commercial scanners, or your own tooling?

Accepted Answer

Both, but the testing itself is manual. We use scanning and custom tooling to speed up reconnaissance, but a person decides what to test next based on what's already been found, that's what makes it a real penetration test rather than a scan with a report attached.

Question 11

Can this be scoped to satisfy NIS2 or DORA testing expectations?

Accepted Answer

Yes. We regularly scope engagements for organizations working toward NIS2 Article 21's risk-management measures or DORA's broader ICT testing obligations. Threat-led penetration testing (TLPT) under DORA Articles 26–27 is a narrower, regulator-designated program most entities won't need, we can help clarify which obligation actually applies to you.

Question 12

Can you test APIs without a UI?

Accepted Answer

Yes. We regularly test headless and internal-only APIs directly, using API specifications, Postman collections, or documentation you provide.

Question 13

Do you test in staging or production?

Accepted Answer

We recommend a staging or dedicated test environment where possible, but can safely scope production testing with rate limiting and change windows agreed in advance.

Question 14

Do you test GraphQL APIs the same way as REST?

Accepted Answer

The underlying testing discipline is the same, authentication, authorization, injection, business logic, but GraphQL introduces its own risks (query depth/complexity abuse, introspection exposure, batching attacks) that a REST-focused methodology alone wouldn't catch. We scope for whichever API style you actually run.

Question 15

Do you map findings to the OWASP API Security Top 10 specifically?

Accepted Answer

Yes, alongside the standard OWASP Top 10 where relevant, API-specific issues like broken object-level authorization and excessive data exposure get classified against the OWASP API Security Top 10 directly, since that's the more precise vocabulary for API-specific findings.

Question 16

What if we don't have API documentation?

Accepted Answer

We can work without it, reconnaissance includes reverse-engineering the API surface from client-side traffic, but providing a spec (OpenAPI/Swagger, Postman collection, or similar) lets us spend more of the engagement on testing and less on rediscovering what you already know.

Question 17

How is this different from a penetration test?

Accepted Answer

A penetration test attacks the running application from the outside. Code review reads the source directly, which surfaces different issues, logic flaws and insecure patterns that aren't always reachable or visible through black-box testing alone. Many teams use both together.

Question 18

What languages and frameworks do you cover?

Accepted Answer

Our reviewers work across the common modern web stacks, JavaScript/TypeScript, Python, Java, Go, C#, and PHP among others. Tell us your stack when scoping and we'll confirm fit before starting.

Question 19

Do you review infrastructure-as-code (Terraform, CloudFormation) too?

Accepted Answer

Yes, where it's part of the codebase in scope, misconfigured IaC is a real source of production security gaps, and reviewing it alongside application code catches issues a separate cloud-only review might miss.

Question 20

How is a finding here different from a static analysis (SAST) tool's output?

Accepted Answer

SAST tools flag pattern matches at volume with no judgment about real-world exploitability. Our reviewers trace the actual data flow by hand to confirm whether a flagged pattern is genuinely reachable and exploitable in your application's specific context, every finding we report has that reasoning attached.

Question 21

Can you review a codebase you didn't build?

Accepted Answer

Yes, most of our code review engagements are on existing codebases we didn't write. We don't need historical context to assess current security posture, though a walkthrough of the architecture speeds up scoping.

Question 22

Will testing disrupt production systems?

Accepted Answer

We agree rules of engagement in advance, including blackout windows and any systems requiring careful handling, to minimize risk of disruption during testing.

Question 23

Do you test cloud-hosted networks too?

Accepted Answer

Yes, for cloud-native network configurations (VPCs, security groups, peering), this typically pairs with our Cloud Security service for full coverage.

Question 24

Do you test Active Directory environments specifically?

Accepted Answer

Yes, Active Directory and broader identity infrastructure is one of the most common paths from initial access to full domain compromise, and it's a standard part of an internal network assessment, not an add-on.

Question 25

How do you handle legacy systems that can't tolerate aggressive testing?

Accepted Answer

We agree on handling for fragile or legacy systems during scoping, that can mean lighter-touch testing, a maintenance-window schedule, or excluding a specific system from active exploitation while still assessing its exposure passively.

Question 26

Do you provide a network diagram as part of the deliverable?

Accepted Answer

Yes, where useful for the finding, attack paths and segmentation issues are often clearer shown visually than described in prose alone, and we include diagrams in the report where they add real clarity.

Question 27

Which cloud providers do you support?

Accepted Answer

AWS, Microsoft Azure, and Google Cloud Platform, including hybrid and multi-cloud environments.

Question 28

Do you need production access to test?

Accepted Answer

We typically request read-only or scoped access appropriate to the engagement type, and agree on safe testing boundaries before any active exploitation.

Question 29

Do you assess Infrastructure-as-Code before it's deployed?

Accepted Answer

Yes, where IaC (Terraform, CloudFormation, Bicep) is provided, reviewing it pre-deployment catches misconfigurations before they ever reach a live environment, which is cheaper to fix than finding the same issue live.

Question 30

Can you assess a multi-cloud environment in one engagement?

Accepted Answer

Yes, we regularly scope engagements spanning AWS, Azure, and GCP together, including how identity and trust relationships are configured across them, which is exactly where multi-cloud environments tend to develop the most overlooked gaps.

Question 31

Do you need standing access to our cloud accounts, or is it point-in-time?

Accepted Answer

Point-in-time, we request scoped, time-boxed access for the engagement itself, not standing access afterward. Access is revoked or rotated once testing and reporting are complete.

Question 32

Is this a one-time engagement or ongoing?

Accepted Answer

Both models are available, a fixed-scope architecture review, or ongoing advisory retainers for teams building out their security function.

Question 33

Can this help with compliance requirements?

Accepted Answer

We provide advisory support aligned to common frameworks and customer security questionnaires, though we recommend pairing with formal compliance/audit specialists for certification.

Question 34

Can you help us prepare specifically for NIS2 or DORA obligations?

Accepted Answer

Yes, this is a common engagement for us. We help map your current posture against NIS2's Article 21 risk-management measures or DORA's ICT risk and testing requirements, and build a prioritized roadmap to close the gaps, though formal regulatory attestation still requires your own compliance/legal review.

Question 35

Which EMEA regulatory frameworks are you familiar with?

Accepted Answer

We regularly work with clients navigating EU frameworks (NIS2, DORA, GDPR), UK frameworks (NCSC guidance, Cyber Essentials), and Middle East frameworks, including the UAE's Information Assurance Regulation and Saudi Arabia's Essential Cybersecurity Controls, tell us your specific regulatory context during scoping.

Question 36

Do you provide vCISO-style ongoing advisory, not just a one-time assessment?

Accepted Answer

Yes, alongside fixed-scope architecture reviews, we offer ongoing advisory retainers for organizations that want continued strategic guidance without hiring a full-time CISO.

Question 37

Do you provide 24/7 incident response?

Accepted Answer

We support incident response readiness, building your plans, playbooks, and detection capability. Contact us to discuss active incident response and retainer options.

Question 38

Can this follow directly from a penetration test?

Accepted Answer

Yes, this is a common pairing. We can implement fixes and hardening directly from testing or consulting findings, then validate the results.

Question 39

Can you deploy and tune a SIEM or detection platform for us?

Accepted Answer

Yes, detection engineering, including deploying and tuning SIEM/EDR tooling to your actual environment rather than leaving it on noisy defaults, is a core part of this service.

Question 40

Do you work with our existing security tooling, or only recommend replacements?

Accepted Answer

We work with what you already have wherever it's fit for purpose, the goal is closing gaps and tuning what exists, not replacing tooling for its own sake. We'll flag it directly if something genuinely isn't serving its purpose.

Question 41

How do you prioritize which findings to remediate first?

Accepted Answer

By actual exploitability and business impact, not just severity score, a critical-rated finding with no realistic exploitation path gets deprioritized behind a medium-rated one that's trivially reachable from the internet.

Question 42

Do you need admin access to our tenant?

Accepted Answer

We typically request a read-only Global Reader or scoped custom role, enough to review configuration without needing standing admin access to your tenant.

Question 43

Do you manage Microsoft 365 directly, or just assess it?

Accepted Answer

Both, we can assess your current configuration, and separately support implementing and managing the fixes across any Microsoft 365 product.

Question 44

Do you assess compliance with UK NCSC or EU NIS2 guidance for M365?

Accepted Answer

Yes, for organizations operating under UK NCSC guidance or EU NIS2's risk-management measures, we assess your tenant configuration against those baselines alongside Microsoft's own security recommendations.

Question 45

Can you assess a hybrid environment with on-prem Active Directory sync?

Accepted Answer

Yes, hybrid identity (on-prem AD/LDAP federation into Entra ID) is explicitly part of what we assess, since misconfiguration in the sync layer is a common way an on-prem compromise becomes a cloud compromise.

Question 46

Do you support GCC High or other government/sovereign M365 environments?

Accepted Answer

Tell us your specific tenant environment during scoping, the core assessment methodology applies, though sovereign/government cloud environments sometimes have additional configuration surfaces worth confirming fit for before starting.

Question 47

Can you build on our existing codebase, or only from scratch?

Accepted Answer

Both. We regularly take over or extend existing applications, and will flag any pre-existing security concerns we find along the way rather than working around them silently.

Question 48

Do you also test what you build?

Accepted Answer

We build to the same standard we test against, and can pair a build engagement with an independent penetration test for an extra layer of validation before launch, the same way we'd recommend for any production system.

Question 49

Do you build custom applications, or only on platforms like Shopify/WordPress?

Accepted Answer

Both, we build fully custom applications as well as platform-based sites (Shopify, WordPress, Webflow, and others), and will recommend whichever approach actually fits your requirements rather than defaulting to one.

Question 50

Is hosting included, or do we need our own infrastructure?

Accepted Answer

We can handle hosting and deployment as part of the engagement, or deploy to infrastructure you already manage, this gets scoped alongside the build itself.

Question 51

What happens if we want to make changes ourselves after launch?

Accepted Answer

You get full source code ownership and documentation at delivery, you're never locked into us for future changes, though ongoing support and maintenance is available if you'd rather not manage it in-house.

Question 52

Do you assess AI tools we use, or only ones we build ourselves?

Accepted Answer

Both, third-party AI tools and APIs you've integrated, and systems you're building in-house. The risk (and the review) looks similar either way: what data goes in, what comes out, and who can access it.

Question 53

We don't have a security team, can you help us adopt AI safely from scratch?

Accepted Answer

Yes, this is a common starting point. We can review a specific tool or integration before rollout, or work through your broader AI adoption plan with you.

Question 54

Do you test for prompt injection specifically?

Accepted Answer

Yes, prompt injection and jailbreak resistance testing is a core part of assessing any AI system that accepts user or third-party input, since it's one of the most common ways an LLM-integrated application's intended behavior gets subverted.

Question 55

Can you review a specific AI vendor's data handling before we adopt it?

Accepted Answer

Yes, reviewing what a third-party AI vendor actually does with input data, logging, and retention before you integrate it is exactly the kind of gap this service is meant to close, often before a data-handling issue becomes a real exposure.

Question 56

Do you map AI-specific findings to a recognized framework?

Accepted Answer

Yes, findings are classified against the OWASP Top 10 for Large Language Model Applications and, where relevant, MITRE ATLAS, the adversarial-threat framework specifically for AI systems, so findings use a vocabulary your team or auditors will recognize.

Question 57

Do we need to already be a Cloudflare customer?

Accepted Answer

No, we can review and harden an existing Cloudflare setup, or help you plan and configure a migration onto Cloudflare from scratch, with security configured correctly from day one instead of retrofitted later.

Question 58

How is this different from your Cloud Security service?

Accepted Answer

Cloud Security covers your AWS, Azure, or Google Cloud infrastructure and identity layer. This service is specifically the edge Cloudflare sits in front of that, WAF, DDoS, DNS, Bot Management, and Zero Trust. The two are frequently scoped together, since Cloudflare commonly sits in front of exactly those cloud environments.

Question 59

Can you tune an overly aggressive WAF that's blocking real visitors?

Accepted Answer

Yes, false-positive tuning is one of the most common reasons teams end up here. We review which managed and custom rules are actually firing, and tune sensitivity and scope so legitimate traffic isn't the collateral damage of a rule set nobody's revisited since it was turned on.

Question 60

Do you configure Zero Trust / Cloudflare Access for remote access?

Accepted Answer

Yes, Cloudflare Access (part of Cloudflare One / Zero Trust) is a common alternative to a traditional VPN for remote and internal application access, and configuring its policies correctly is part of this service.

Question 61

Do you help with DNS security if we move our DNS to Cloudflare?

Accepted Answer

Yes, DNSSEC and email authentication (SPF, DKIM, DMARC) configuration is part of this service, and ties directly into our broader email security work if you're also reviewing Microsoft 365 or another mail platform.

Question 62

Do we need to already have GuardDuty and Security Hub enabled?

Accepted Answer

No, we can review and harden an existing setup, or help you enable and configure these services correctly from the start if they're not running yet.

Question 63

How is this different from your Cloud Security service?

Accepted Answer

Cloud Security covers architecture-level review across AWS, Azure, and GCP. This service is the deeper, AWS-specific configuration and hardening work, IAM, GuardDuty, Security Hub, Config, KMS, CloudTrail, once AWS is confirmed as the environment in scope. The two are frequently scoped together.

Question 64

Can you review a multi-account AWS Organization?

Accepted Answer

Yes, reviewing IAM, GuardDuty, and Security Hub configuration across a multi-account Organization, including how trust relationships and delegated administration are set up between accounts, is a common and often the most valuable version of this engagement.

Frequently asked questions.

Penetration Testing

Web & API Security Testing

Secure Code Review

Network Security Testing

Cloud Security

Cybersecurity Consulting

Security Engineering

Microsoft 365 Assessment

Web & App Development

AI Services & AI Security

Cloudflare Security Services

AWS Security Services

Ready to see where your defenses actually stand?