Threat hunting vs penetration testing: which one answers your question first
Choose threat hunting when the question is whether attackers are already inside your environment. Under NIST SP 800-53 Rev. 5 control RA-10 Threat Hunting, a hunting capability searches for indicators of compromise and looks for threats that have evaded existing controls, so its output is evidence of present or past intrusion. Choose penetration testing when the question is whether an outside attacker can get in. A penetration test is an invited attempt to break in, and its results describe the paths that were exploited and the controls that failed to stop them. The wording from the board or regulator usually decides which question you are answering. "Is anyone in here now?" points to hunting, while "can someone reach our customer data?" points to a test.
NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and each approach has a different weakness. A penetration test uses real exploits against production systems and data, so it carries high risk and needs written rules of engagement that name targets, time windows and stop conditions. NIST provides a template for these in Appendix B of the SP 800-115 guide. Hunting depends on what your logging captures, so its coverage is only as wide as your telemetry. The useful link between the two is the handoff: each technique a tester used should become a hunting hypothesis, and each hunt gap should become a test case. CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used.
Run both when the answer to either question would change a decision. Confirm which SP 800-53 baseline applies before committing budget: RA-10 is not selected in any SP 800-53B baseline, while CA-8 penetration testing is selected only in the high baseline, with CA-8(1) independent testers also in high. If you are a designated financial entity under DORA, check with your competent authority, since Article 26 requires threat-led penetration testing at least every 3 years for entities it identifies. When you ask a hunting provider for a quote, request the hypotheses it will test, the data sources in scope and the retention terms for findings. When you ask a testing provider, request a mapping from each technique to the detection that should have fired. Those two documents show whether the work answers your question or only produces a report.
How threat hunting and penetration testing compare across scope, method and output
This table compares threat hunting and penetration testing on goal, starting assumption, inputs, outputs and control references. Read it to decide which activity answers your question: is an attacker already inside, or can an outsider get in and what would they reach? The main takeaway is that the two feed each other, so a test should end with detection content that a hunt can use.
| Dimension | Threat hunting | Penetration testing |
|---|---|---|
| Core goal | Find adversaries already present that existing controls missed, then disrupt them | Show whether a defined target can be compromised and what an attacker could reach from it |
| Starting assumption | Attackers may already be inside and evaded preventive and detective controls | The target may be exposed, and the question is whether a controlled exploit path exists |
| Control reference | NIST SP 800-53 Rev. 5 RA-10 Threat Hunting, which is not selected in any SP 800-53B baseline; confirm whether your program maps to it | NIST SP 800-53 Rev. 5 CA-8 Penetration Testing, selected only in the high baseline per SP 800-53B; CA-8(1) independent team is also high-only |
| Primary inputs | Telemetry from endpoints, network and cloud logs, threat intelligence, ATT&CK technique knowledge base and an asset inventory | Rules of engagement, asset and scope list, reconnaissance data and agreed test accounts; threat intelligence is optional unless the test is threat-led |
| Who performs the work | Internal or contracted hunters with access to detection tooling; confirm analyst skills and log access in your environment | Internal testers or an external firm; CIS Safeguards 18.2 and 18.5 call for external and internal tests, and certification requirements vary by provider |
| Method at a buyer's level | Hypothesis-driven searches of logs for techniques, followed by triage and containment decisions | Scoped attempts to exploit and move through targets under a written authorization, with reporting of validated paths |
| Outputs | Confirmed or ruled-out hypotheses, incident leads, new detection rules and hunt write-ups | Validated findings with evidence, risk context and remediation guidance; detection content only if the scope requires it |
| Typical cadence | Continuous or recurring, scheduled around new intelligence; confirm staffing needs with your provider or team | Periodic, with CIS Safeguards 18.2 and 18.5 asking for at least annual tests; NIST suggests interspersing with regular scanning |
| Feedback loop | Hunt gaps and missed techniques become test scenarios and validation targets | Techniques used by testers should be checked against detections, per CIS Safeguard 18.4 |
Which approach fits which buyer situation
When you already have signs of an intruder, such as unexplained credential use, outbound traffic to unfamiliar destinations, or an alert you cannot close, threat hunting leads. NIST describes RA-10 as an active defense capability that searches for indicators of compromise and threats that evade existing controls. A penetration test asks whether an outsider can get in, which is the wrong first question once someone may already be inside.
- Hunt first: Build hypotheses from the suspicious activity and search endpoint, identity and network data for indicators of compromise across the affected period.
- Keep testing out of the incident: A penetration test run during active response can alter logs, alert the attacker or muddy the evidence trail. Schedule it separately after containment.
- Structure hypotheses with ATT&CK: The MITRE ATT&CK FAQ describes the knowledge base as a taxonomy of adversary behavior, which helps turn a suspicion into testable techniques.
- Plan the retest: After the intrusion is contained, CIS Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques testers used.
Confirm with your incident response provider and counsel how evidence will be preserved before any hunt or test begins.
When the question is what an outsider can reach from the internet, a scoped external penetration test leads. CIS Safeguard 18.2 asks for external penetration tests at least annually, and Safeguard 18.5 asks for internal tests at the same cadence, so this work recurs every year. Threat hunting searches your environment for attackers already present, so it does not show which of your public services an attacker could reach in the first place.
- Define scope in writing: List in-scope IP ranges, domains and cloud endpoints in the rules of engagement, using the template in NIST SP 800-115 Appendix B as a starting point.
- Accept that exploitation happens: NIST SP 800-115 notes that penetration testing uses real exploits against production systems, so agree on risk limits and change windows in advance.
- Feed results into hunting: If the test reaches an unusual access path, turn the techniques it used into hunt hypotheses that check whether anyone has used the same route.
- Calendar the cadence: Confirm that your schedule meets the annual expectation for both external and internal tests.
Ask the provider whether the work is manual, automated or a mix. PCI SSC guidance states that simply running an automated tool does not satisfy its penetration testing requirement, so check how your assessor will judge the output.
NIST SP 800-53B selects CA-8 and its enhancement CA-8(1) only in the high baseline. For a high-baseline system, penetration testing and an independent test team are formal requirements, so the test is the leading control for that system. RA-10 threat hunting is not selected in any SP 800-53B baseline, so hunting is a capability you choose to build, and an assessor will not verify it through the baseline alone. The NIST OSCAL content lets you check each baseline selection directly.
- Confirm the categorization: Check that your system's impact level places it in the high baseline before you scope CA-8 work.
- Use an independent team: CA-8(1) calls for an independent penetration testing agent or team, so the people who operate the system should not run its test.
- Document the hunting decision: Because RA-10 is not baseline-selected, record your reasoning for hunting as a risk decision, with the owner and review cycle.
- Keep the evidence chain: Retain rules of engagement, test reports, remediation tickets and retest results for the assessor.
Ask your assessor which controls they will examine for this system and whether your control mappings match the current OSCAL baseline files.
With thin logging, a threat hunt has little to search, so a clean result tells you little. A penetration test does not depend on your telemetry to run, but its value depends on your detections to show whether its activity was noticed. In this situation, the penetration test leads, and visibility work follows. Hunting should wait until the data you need is being collected and retained.
- Use the test to find blind spots: Techniques that succeed without any alert show where telemetry is missing, so the report becomes your priority list for logging.
- Validate after each fix: CIS Safeguard 18.4 expects security measures to be validated after each test so that detections cover the techniques testers used.
- Hunt only where data exists: Confirm that endpoint, identity and network sources keep enough history to search the period you care about.
- Avoid false assurance: A hunt that finds nothing on sparse logs does not prove absence. Record coverage limits in the report.
Ask the provider to list which log sources the test assumed were visible and which it confirmed through its own observations, so you can judge how much of the result depends on your gaps.
Teams writing detection rules need evidence of how attackers move through their environment. Penetration test findings and hunt results both supply that evidence, but they answer different questions. A test shows which techniques reached an objective, and a hunt shows which behaviors appear in your own logs. Use the test to decide what to detect, then use hunting to confirm what the detection finds in practice.
- Map findings to techniques: Tag each finding with its ATT&CK technique and write one detection per technique, tested against the attack path that produced it.
- Promote hunt queries: Turn hunt queries that return repeatable, useful results into scheduled alerts, and retire the ones that only produce noise.
- Validate coverage: CIS Safeguard 18.4 expects detections to cover the techniques testers used, so keep a record that links each rule to a test.
- Avoid a single source: Test paths are one tester's route through your environment, so pair them with hunt results before treating them as the full set of behaviors to detect.
Ask providers to deliver findings with technique identifiers, attack steps and the log evidence each step produced, so your team can write and test rules without repeating the test.
What each approach finds and what it misses
Threat hunting and penetration testing answer different questions about the same environment. One asks whether an adversary is already inside, the other asks whether an outsider can get in and what that access would reach. The cards below set out what each surfaces and where each one goes blind.
Dwell-time activity in your telemetry
Threat hunting starts from the assumption that an attacker may already be present and searches logs, endpoints and identity records for activity that has persisted over time. Hypotheses come from threat intelligence and from the ATT&CK techniques relevant to your sector. The output is a set of confirmed or cleared hypotheses and new detection logic. Check whether your hunters can query the data sources the hypothesis needs, and how far back that data is kept.
Exposures without telemetry
Hunting can only find behavior that your sensors record. A weakness in a service no one instrumented, or a path that never writes a log entry, produces nothing to query. Penetration testing can expose these gaps because the tester probes the system directly. When you scope a hunt, list the data sources you collect and the ones you do not, then decide which gaps a penetration test should cover.
Behaviors that evade existing controls
Threat hunting targets adversary behavior that has already slipped past firewalls, intrusion detection and SIEM rules. NIST describes it as an active defense that searches for advanced threats earlier in the attack sequence. Ask whether your team has a documented hunt cadence and a way to turn each finding into a rule for the monitoring stack. Without that loop, hunting produces one-time answers rather than lasting coverage.
Exploitable weaknesses and attack paths
Penetration testing uses real exploits and chained techniques to show which weaknesses an outsider can reach and what they lead to. NIST SP 800-115 treats it as high risk because it runs against production systems. The result is a validated attack path with evidence, which helps you prioritize fixes. Confirm the rules of engagement, testing windows and data handling rules before the test begins.
Persistence already in place
A penetration test is scoped to a time window and a set of targets, so it does not establish whether an attacker placed backdoors before the engagement began. A clean test report does not prove the environment is clear. Pair the test with a hunt, and ask the test provider how it will report signs of prior compromise it encounters. Treat any such finding as an incident, with separate handling.
Automated tools do not replace manual testing
PCI SSC's penetration testing guidance describes penetration testing as essentially a manual process and states that simply running an automated tool does not satisfy the penetration testing requirement. Scanners and automated checks help find known issues, but they do not replace a tester who chains weaknesses. When you buy a test, ask who performs the manual work, how much time goes to it, and whether the scope includes attack path analysis.
How penetration test techniques feed hunting hypotheses and detection rules
A penetration test pays off twice when its report is used as an input to detection work, not only as a list of fixed findings. The pentest report should record each technique the testers used, the host or account involved, the time window and what the defenders did or did not see. Those records become the raw material for two defensive outputs: hunting hypotheses that a threat hunting team tests across historical telemetry, and detection rules that a SIEM or endpoint tool runs continuously. Ask your testing provider to deliver the technique log as a structured artifact, not only as narrative prose, and to state which logs were in scope during the test so that gaps in visibility are documented alongside the attack path.
CIS Controls v8.1 Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used. In practice, this means a closed loop: for each technique in the report, the blue team confirms whether an alert fired, whether the alert reached an analyst, and whether the response matched the playbook. Where nothing fired, the technique becomes a hunting hypothesis (for example, a credential-based lateral movement pattern that the test proved possible in your identity logs) and a candidate detection rule. Map each technique to MITRE ATT&CK, which the ATT&CK FAQ describes as a knowledge base of adversary behavior and a taxonomy for adversarial actions across their lifecycle. Shared technique IDs make the mapping auditable and let you compare coverage over successive tests. Confirm with your provider that the report uses ATT&CK technique identifiers and names the version used.
Treat the loop as a decision about ownership. Someone must decide which hypotheses are worth an hour of hunting and which detection rules go to production after tuning for false positives, and that person needs the test evidence, the log sources and the affected systems in one place. Plan for the rules to be retested, because a detection that fired during the test may stop firing after a log source changes or a parser breaks. Before you accept a pentest scope, confirm that it will include the technique logging and the post-test validation window your team needs, since neither is guaranteed by a standard engagement.
How to run both in one annual cycle
This sequence lets one annual cycle produce a scoped penetration test, a mapped set of techniques, and detections that are checked against the same behaviors. Each step hands a defined output to the next, so the test informs the hunt and the retest confirms the result.
Set the schedule and frequency
The buyer's security or risk owner decides how often penetration tests run and which systems they cover, because no supplied source sets a single frequency for every organization. For reference, CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, which is a useful starting point to confirm against your own regulatory and contractual obligations. The output is a written calendar that names the test windows and the owner of each one.
Scope the test with rules of engagement
The security lead and the testing provider agree on targets, testing windows, permitted techniques, emergency contacts and data handling. NIST SP 800-115 provides a rules of engagement template in Appendix B, which is a practical base for this document. The output is a signed rules of engagement that states what testers may do, what they must not touch, and who is told when activity starts and stops.
Run the penetration test
The testing provider performs the agreed work, which NIST SP 800-115 describes as using real exploits against production systems and data and carrying high risk, so the scope from the previous step matters. Your team should log the start and end times of each activity so that defenders can later match testing traffic to alerts. The output is a findings report with a technique-level narrative of how access was gained, moved and maintained.
Map observed techniques to ATT&CK
The team translates each step in the report into MITRE ATT&CK techniques, using the Enterprise matrix as the reference vocabulary. This turns a one-off narrative into a list that detection engineers and threat hunters can reuse. The output is a technique inventory with the systems, accounts and log sources where each technique was seen, plus a note of which techniques were not tested.
Write hunting hypotheses and detection rules
Threat hunters turn each mapped technique into a testable hypothesis, such as whether a given credential misuse pattern would appear in authentication logs if an attacker used it. Engineers then draft detection rules for techniques that should be alerted on and record where the telemetry is missing. The output is a short hypothesis register and a set of rule changes, each linked to the technique it covers.
Hunt against historical telemetry
Hunters run the hypotheses against logs from the period that overlaps the penetration test and against older data, looking for activity that matches the techniques in case an attacker was already present. This is the step where threat hunting, under NIST SP 800-53 RA-10, searches for indicators that existing controls may have missed. The output is either a documented negative result with its data coverage or an incident handed to response.
Retest and validate the detections
After the new rules are deployed, the team reruns the same techniques in a controlled retest and confirms that alerts fire and reach the right responders. CIS Safeguard 18.4 asks for security measures to be validated after each test so that detections cover the techniques testers used. The output is a retest record that shows each technique as detected, partly detected or still open, which becomes the starting point for the next annual cycle.
What you receive from each approach
This table compares what each approach hands back to your team, from hunt hypotheses and detection content to a rules of engagement document and validated findings. Read it as a checklist for the written scope: the items in each row are typically included, but format, depth and retention vary by provider and must be confirmed before work starts.
| Deliverable | Threat hunting | Penetration testing |
|---|---|---|
| Scope or authorization document | Hunt scope, data sources and time window agreed with the SOC; no authorization letter against third parties | Rules of engagement covering targets, testing windows, permitted techniques, escalation contacts and stop conditions, modeled on the NIST SP 800-115 Appendix B template |
| Core analytic output | Written hunt hypotheses, the queries or searches run, and the evidence reviewed for each | Technique narrative showing the attack path, the steps taken and what each step proved |
| Findings | Findings on suspicious activity, marked as confirmed, suspected or benign, with the affected hosts and accounts | Validated findings with proof of exploitation or access, and the conditions needed to reproduce each one |
| Risk ratings and severity | Impact and confidence on each suspicious activity, aligned to incident triage rather than a vulnerability score | Risk ratings for each validated weakness, typically using a scoring method the buyer agrees in advance |
| Containment and remediation guidance | Containment recommendations for confirmed intrusions, with a hand-off to incident response | Remediation guidance per finding and retest scope, usually without operating the fixes |
| Detection content | Detection rules, analytics or searches written from hunt results, ready to load into the SIEM after testing | Usually none as a standard deliverable; detection gaps are reported so the defenders can write rules |
| Format and retention | Confirm whether hunt queries, raw evidence and timelines are handed over and how long the provider keeps them | Confirm report format, evidence handling, how long working papers are retained and when they are destroyed |
What drives cost and effort for each approach
Threat hunting and penetration testing are paid for in different ways. Hunting cost follows the data you collect and keep, while penetration testing cost follows the scope, the manual work and the legal setup around each engagement. The cards below separate the drivers so you can ask each provider for the right breakdown.
Telemetry coverage and retention
Hunting depends on logs you already collect. Before any hunt, confirm which endpoints, identity events, network flows and cloud audit logs reach your store, and how many days of history they keep. Short retention limits how far back a hunter can search for dwell time. Ask any hunting provider to price the data sources and retention window separately from the analyst hours, because storage and query capacity recur every month.
Environment size and hunt count
Hunting effort grows with the number of hosts, identities and cloud accounts in scope, and with how many hypotheses the team tests each cycle. A hunt against one domain is a different job from a hunt across a multi-region estate. Ask for the hunt count per quarter, the systems covered by each hypothesis, and whether the quote assumes your existing SIEM or a new query platform.
Pentest scope breadth and test layers
Penetration testing cost rises with each added layer, such as external network, internal network, web applications, APIs, cloud configuration and Active Directory. Each layer adds planning, access setup and reporting time. Ask the vendor to list the layers in the written scope and to price each one, so you can see which layers you can drop without losing the coverage your auditor or board expects.
Manual effort in testing
PCI SSC's Penetration Testing Guidance describes penetration testing as essentially a manual process and says that running an automated tool alone does not meet the penetration testing requirement. Most of the fee therefore pays for a tester's time on attack paths, validation and retesting. Ask how many tester days the quote assumes, who performs them, and how the report explains what was verified by hand.
Rules of engagement and legal authorization
Penetration tests use real exploits against production systems, so the rules of engagement and the written authorization letter define what is safe to touch and who can stop the work. NIST SP 800-115 provides a rules of engagement template in Appendix B. Ask for legal review time, third-party hosting permissions and an emergency contact list in the quote, because these steps are fixed costs that appear before any testing starts.
One-time versus recurring spend
A penetration test is usually a discrete engagement with a report and a retest, while threat hunting is an ongoing function that needs analysts, data pipelines and tuning every month. CIS Safeguard 18.4 asks that security measures be validated after each test, which adds detection tuning to the test cycle. Ask each provider to split the quote into one-time setup, recurring operations and per-engagement testing, and to state what renews automatically.
Questions buyers ask before hiring help for hunting or pentesting
Can we run threat hunting ourselves without outside help?
Yes, if you already have telemetry, analysts who know your environment, and a way to write and test hypotheses. Threat hunting is an active defense practice: NIST describes it under RA-10 as a capability that searches for indicators of compromise and detects, tracks and disrupts threats that evade existing controls. The work depends on log coverage in your SIEM and EDR, enough baseline knowledge to spot abnormal activity, and time for analysts who are not on incident queues. If one of those is missing, outside help usually goes to building the hypothesis library, the data sources or the first hunt cycles. Ask any provider to state in writing which data sources they will query, which systems they will access, and what they will hand back for your team to run.
What does a penetration test need from our team?
A penetration test needs a written scope, named technical contacts, authorized test accounts where relevant, and agreed rules of engagement. NIST SP 800-115 includes a rules of engagement template in Appendix B, which is a sound starting point for the document your team signs. Your staff also need to decide in advance how testing will be coordinated with operations, which production systems are off limits, and who can halt the test if it causes harm. Expect to provide asset lists, network diagrams, and access for on-site or remote testers. The more of this is settled before kickoff, the less time testers spend on discovery and the less risk of an unplanned outage. Request the rules of engagement and the escalation contacts in writing before work begins.
How long does each engagement take?
Duration depends on scope, system count, access model and how quickly your team can respond, so no single figure applies. A narrow external test and a multi-layer internal assessment differ by a wide margin. For threat hunting, the duration depends on how many hypotheses you run, how much historical data is retained, and whether findings lead to incident response. Ask each provider for a timeline tied to the written scope, with separate phases for preparation, execution and reporting, and a list of client dependencies that could extend the schedule. Treat any timeline that is not linked to defined assets and data sources as a sales estimate, not a plan.
Does a penetration test count as threat hunting?
No. A penetration test invites testers to break in and measures whether your controls stop them, while threat hunting searches your environment for attackers who may already be inside. NIST SP 800-115 treats penetration testing as a target vulnerability validation technique that uses real exploits against production systems, which carries high risk. Threat hunting, under RA-10, works on the data your systems already produce. The two inform each other: techniques that testers used can become hunting hypotheses, and CIS Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques used. A pentest report alone does not show whether an intruder was present before the test began.
Which baseline requires CA-8 penetration testing?
In NIST SP 800-53B, CA-8 Penetration Testing is selected only in the high baseline, and its enhancement CA-8(1) for an independent penetration testing agent or team is also in the high baseline. If your system is categorized as moderate or low, CA-8 is not a required control under that baseline, though you may still test voluntarily. Confirm your baseline with your authorizing official or compliance lead, because your categorization depends on the system's impact level and not only on its industry. Your assessor will expect the test scope, independence arrangements and findings handling to be documented, whichever baseline applies.
Does RA-10 threat hunting apply to our baseline?
Based on the SP 800-53B baselines, RA-10 Threat Hunting is not selected in any baseline, so it is not a required control under the standard baselines. That does not mean hunting is irrelevant. Your organization can adopt it voluntarily, or a sector regulator, contract or internal risk policy can require it. Confirm the requirement with your compliance lead and any sector regulator you report to. If you adopt hunting as a practice, write down its scope, data sources, hypothesis process and how outputs reach incident response, so auditors can see how it operates.
How do hunting and pentesting change our SIEM or EDR spend?
Both can raise your SIEM and EDR costs because they need more telemetry and longer retention, but the spend is driven by the data sources you enable, not the service names. Hunting usually needs wider log coverage, longer searchable history and endpoint data that can be queried across hosts. Pentesting does not require new tooling, but its findings may show missing logs or detection gaps that you then have to fix. Ask providers to list which logs and detections each recommendation depends on, and to state whether the work includes tuning your existing platform or only reporting. Your licensing model, whether by event volume, endpoint count or storage tier, determines how that growth is billed.
How DeployOpen scopes and delivers threat hunts and penetration tests
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it runs security testing against those same environments. For a threat hunt or a penetration test, that means the work starts from your infrastructure, your logs and your access model rather than from a generic template. Before any work begins, the scope, deliverables and timelines are agreed in writing. For a threat hunt, that scope should name the data sources to search (endpoint telemetry, identity logs, network flows), the time window, the hypotheses to test and the systems that are out of bounds. For a penetration test, it should name the targets, the authentication levels, the permitted techniques and the rules of engagement, including what happens if testers find signs of an existing compromise.
Most engagements are fixed-scope, so the quote follows from the written scope rather than from a price list. Ask for the components that drive effort: the number of log sources and the retention you need searched, the number of applications or network segments in scope, whether testers need authenticated access, and whether findings must be retested after fixes. Ask which deliverables are included, such as hunt reports, detection rules, a validation summary or a remediation plan, and which are optional. Ongoing hunting, testing and upgrade work can be covered by a retainer, which suits teams that need continuous coverage rather than a single exercise. Confirm the handover model as well: who owns the detection rules and test evidence after the engagement, and how they are stored in your environment.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Where a framework asks for regular testing or validation, the evidence DeployOpen produces, such as scope documents, test records and remediation tracking, is intended to support the assessor's review. Before you commit, confirm with your assessor which evidence formats they accept and which control references your testing must map to, and confirm with DeployOpen how the outputs will be packaged for that purpose.
How DeployOpen scopes, delivers and supports security testing
DeployOpen plans, implements, tests, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and runs security testing alongside them. For threat hunting versus penetration testing, we agree the question, data access and boundaries in writing first, then deliver findings your detection and testing teams can act on.
How we scope
- Written scope states which hosts, accounts, log sources and time ranges a hunt or test covers.
- Rules of engagement define permitted techniques, testing windows, production limits and emergency contacts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- Hunting hypotheses are drawn from your threat model, prior incidents and penetration test findings.
- Penetration testing follows a documented methodology, with manual validation of any automated results.
- Detection rules and queries are written against your own logging platform and tested before handover.
How we hand over
- Reports separate confirmed compromise indicators from hypotheses, with evidence and reproduction steps.
- Each penetration test finding is mapped to the detections that should have fired and whether they did.
- Documentation covers queries, rules, scope decisions and open items for your security operations team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
- Retained hunting cycles can rerun hypotheses against new log sources and updated threat intelligence.
- Confirm retainer scope, response expectations and reporting cadence with us in the written quote.
