About
SecIQ

The name

SecIQ is built on a deliberate duality. Sec is security — stability, protection, the discipline of keeping things intact. IQ is intelligence — strategy, foresight, the habit of thinking a move ahead. Together they describe the difference we care about: not simply defending a system, but understanding it well enough to anticipate how it will be attacked.

That is also what the mark represents. It fuses a brain with a circuit — human judgement joined to system logic — because in practice neither one is sufficient. Tooling covers ground; people understand consequence.

How we work

Every SecIQ engagement is run to the same set of practices, whatever the platform. They exist because each one was learned on a delivered engagement, and each one changes what you receive.

Independent, and structurally so

We do not resell security products, take vendor commission or operate a partner programme that pays us for recommendations. That is a structural choice rather than a stated value: when a consultancy's revenue depends on what it recommends, its advice is compromised whether or not anyone intends it to be. If the right answer to your problem is a configuration change, a process change, or doing nothing at all, we are free to say so.

Scope is verified independently before any active testing

No packet is sent in anger until the target list has been verified and signed off. A passive reconnaissance stage — passive DNS, certificate transparency logs and routing attribution — establishes what the organisation actually owns, and we do not treat anyone's asset inventory, including yours, as authoritative for what is safe to test.

Asset inventories are routinely wrong, and testing a system its owner did not authorise is a criminal offence. Independent verification protects you from both.

Findings are validated, not scanner output

Prove-or-disprove is a named phase of every engagement, not a courtesy. Each reported finding carries evidence, reproduction steps, timestamps and affected-asset references. We distinguish a confirmed exploited finding from a validated attack path, so you know exactly what was proven and what was inferred.

A vulnerability is not cited until the build number proves it

No finding cites a published vulnerability identifier until the observed build has been confirmed against the vendor's fixed-build advisory. Where that cannot be proven, the finding is downgraded to a configuration observation rather than reported as a CVE. This is what stops a report turning into an internal re-verification exercise for your engineers.

Every finding carries its confirmation status

Each finding is labelled with one of four states: configuration gap, validated, confirmed exploited, or retracted. A reader can see how much weight each finding carries instead of everything being flattened to one level of confidence, and a retracted finding stays in the record with its reason rather than quietly disappearing.

Non-destructive by default

Impact and exploitability are demonstrated without destructive exploitation or data modification. Where a control has to be exercised to be tested — a ransomware-protection trigger, an endpoint detection rule — it is done with benign, disclosed test material and coordinated with your operations team in advance.

Attack chains, not just a list

We report multi-step chains from a realistic attacker starting position to a business outcome, and rate them on cumulative impact rather than the arithmetic of their component scores. A report can truthfully contain no single Critical vulnerability and still carry a Critical-rated attack chain.

Remediation is sequenced to break chains. Breaking one link usually collapses the whole chain, which is cheaper than clearing severity buckets in order.

A rating method we will defend

CVSS v4.0 is the standard, with the exploit-maturity modifier stated on every vector — attacked, proof-of-concept, or unreported — and CVSS v3.1 where your vulnerability management platform requires it. Attack chains are rated qualitatively using OWASP Risk Rating and a qualitative risk matrix of the kind described in ISO/IEC 27005:2022 Annex A.

We also state plainly what CVSS does not measure: chaining, environmental criticality, compensating controls and assumed attacker start position. Saying so up front settles most rating disputes before they start. Severity challenges are reviewed against evidence after the readout. Ratings are reviewed, never bargained.

Critical findings do not wait for the report

Anything actively exploitable is issued as a standalone interim notice during testing, with enough detail to act on the same day.

Root causes, not instances

Where hundreds of findings share one architectural cause, they are reported as one systemic pattern with one centralised fix. You get a shorter report and a remediation plan that closes the class of issue, not a spreadsheet of symptoms.

We report what works

Controls that hold are documented. Where one site, cluster or build is well hardened, we name it as the internal reference baseline to replicate elsewhere. A report that only lists failures leaves you guessing about the rest.

Honest limitations

We disclose what could not be tested and why, including access-provisioning delays, so you can manage the assets whose security status remains unknown rather than assuming coverage you did not get.

Evidence integrity

Every testing session produces a SHA-256 hash manifest, and the full evidence tree is hashed at engagement close. A documented sanitisation and verification step, including credential-redaction sweeps, runs before anything is delivered. Every report is reviewed before release by a senior consultant who did not perform the testing, with the authority to hold delivery.

Reporting is self-hosted

Reports are produced and stored on infrastructure SecIQ controls rather than on a commercial SaaS reporting platform, and delivered over an encrypted channel agreed with you at scoping. Our sub-processor list is available on request.

Evidence destruction is confirmed in writing

Unless a different retention period is agreed — to cover a retest, a regulatory hold or your own policy — engagement evidence is destroyed thirty days after report acceptance, and the destruction is confirmed to you in writing. This happens as a matter of course, not only when a client thinks to ask for it.

Two audiences, separated

The executive summary and the technical report are separate documents, separate in content and in distribution, classified and transmitted separately. Board readers do not receive exploit detail, and engineers do not receive a summary that hides it.

Structured pre-engagement

A pre-engagement questionnaire and an access and connectivity addendum surface the real critical-path blockers — privilege assignment, tooling permissions, firewall change ownership, session limits for a multi-tester team — before day one rather than during it. Time lost to access problems is time you paid for.

Retest is an entitlement, not an upsell

Retest scope, confirmation window and scheduling are written into the engagement. The retest report shows the original result against the re-validated result for every finding, so closure is demonstrated rather than declared.

A named deputy on every engagement

If the lead tester on your engagement becomes unavailable, a named deputy has already been identified at scoping, and you are notified in writing. You will not discover a change of tester from a new name on a report.

Who we work with

Our work spans organisations that build software and organisations that depend on it — technology and SaaS companies, financial and professional services, healthcare, and businesses handling regulated or personal data at meaningful scale. Engagements range from a focused test of a single application to a certification programme running across a year.

There is no minimum size. What changes with scale is the scope of the work, not the standard of it.

Where we work

SecIQ is registered in England and delivers across EMEA — Europe, the Middle East and Africa — and the United States. Most assessment and advisory work is delivered remotely, which keeps engagements efficient and lets us start quickly. Where work genuinely requires physical presence, such as internal network testing or on-site training, that is agreed during scoping.

Working across these regions also means working across their regulatory regimes: UK and EU GDPR, NIS2, PCI DSS, SOC 2 and the sector-specific rules that sit on top of them. Requirements differ by jurisdiction, and a control set designed for one is not automatically adequate in another.

What we publish

We write long-form, vendor-neutral technical guides on the problems we are asked about most — API authentication, application security architecture, penetration test scoping, ISO 27001 certification and incident response. They are free to read, carry no registration wall, and may be quoted and cited with attribution.

The reason is straightforward: the fastest way to demonstrate how a consultancy thinks is to show the thinking. Read the guides and judge for yourself before you contact anyone.

Company details