How T1526 cloud service discovery exposes an attacker's map of your cloud
Once an adversary has a foothold, the first practical question is what the environment contains and what that access can reach. For a SOC lead, the cloud is often the largest part of that answer: IaaS accounts and subscriptions, identity provider tenants, office suite workloads and a long tail of SaaS applications, each with its own administrative surface. MITRE ATT&CK places this activity under the Discovery tactic, TA0007, which the framework describes as the adversary trying to figure out your environment. T1526 Cloud service discovery covers the part of that effort where the adversary identifies which cloud services are present and in use, so that later steps can be chosen with that knowledge. This page does not describe how the enumeration is performed. It focuses on the telemetry that reveals it and the decisions that determine whether you will see it.
T1526 is most useful to a defender when it is read by platform family. The ATT&CK technique is mapped across IaaS, Identity Provider, Office Suite and SaaS, and each family produces different logs with different owners. IaaS control-plane activity usually sits in the cloud provider's audit trail, identity activity sits in the identity provider's sign-in and directory logs, Office Suite activity sits in the suite's unified audit or admin logs, and SaaS activity depends on what each application exports. A detection that covers only one of these families leaves a map of the others unobserved. Before tuning any rule, confirm which of these logs are enabled, where they are retained, and whether your SOC receives them in near real time. Questions to put to each vendor include retention period, export options and whether administrative read operations are recorded at all.
This page targets MITRE ATT&CK Enterprise version 20.0. ATT&CK releases can rename, deprecate or revoke techniques and change detection guidance, so the detection mappings that follow should be recorded against that version in your rule library and reviewed when you move to a later release. The technique's sibling pages in this pillar cover other discovery behavior, including account and permission group discovery, which often appears alongside cloud service discovery in the same session. Treat T1526 as one signal among several in a discovery sequence rather than as a standalone alert, and decide in advance which combinations of identity, cloud and SaaS events should trigger an analyst review.
Which cloud telemetry reveals service enumeration and where it comes from
This table maps the three telemetry families used for T1526 detection to the audit logs that carry them and the open-source paths that bring those logs into Wazuh, Security Onion or a Sigma pipeline. Read each row as a source to inventory, then confirm field names and data component IDs against the ATT&CK version your team targets. The main takeaway is that most T1526 signal comes from control-plane audit records, so collection gaps usually sit in cloud logging configuration.
| Telemetry | Platform audit source | Open-source collection path | Confirm before relying on it |
|---|---|---|---|
| Cloud Service Enumeration | AWS CloudTrail management events for read-only describe and list calls | Wazuh AWS integration reading the CloudTrail bucket, with events forwarded to Security Onion for hunting | Which describe and list event names your account records and whether data events are enabled |
| User Account Metadata | Entra ID or Okta directory audit and user read events, Google Workspace admin audit logs | Wazuh identity and Office 365 integrations, plus Sigma rules written against identity provider log sources | Whether read-only user lookups are logged or only directory changes, by tenant tier |
| Logon Session Creation | Identity provider sign-in logs and cloud console session start events | Wazuh decoders for sign-in JSON, with Security Onion ingest through its supported collector | Session identifier, client IP and user agent field names for each provider |
| Enumeration from unexpected identities | CloudTrail identity and access key fields, service principal sign-ins | Sigma rules keyed to identity type and source network, converted to your SIEM backend | Field names for role sessions and service principals in each cloud platform |
| Office suite and SaaS admin reads | Microsoft 365 unified audit log and Google Workspace reporting | Wazuh Office 365 integration for management activity, with API pulls into Security Onion where supported | Retention period and license tier that include the read-level audit records you need |
| Collector health | Log delivery status, bucket read errors and checkpoint failures | Wazuh integration status alerts and Security Onion ingest dashboards | Alert on silent sources so gaps do not look like quiet periods |
| ATT&CK data component mapping | Cloud Service Enumeration, User Account Metadata and Logon Session Creation as named data components in the enterprise-attack 20.0 bundle | Sigma and internal rule metadata that references data component IDs for the targeted version | Confirm the DC IDs in the 20.0 bundle, since ATT&CK v18 moved detections to DC IDs and analytics |
Detection logic for cloud service discovery that SOC teams can tune
Cloud service discovery is noisy by nature, because inventory, posture and backup tooling enumerate the same services that an intruder would. The cards below describe four detection ideas in words, with the tuning levers and false positive sources that decide whether each one is usable in a SOC queue.
Breadth of listing calls
Flag a single identity that issues many distinct service or resource listing calls across several services inside a short window, compared with its own historical baseline. The signal is breadth, not volume: one identity listing one service repeatedly is usually a script, while the same identity touching many unrelated services is the pattern that matters for T1526 Cloud service discovery. Tune the window length, the count of distinct services, and an allow list for known inventory and CSPM service accounts. Check the identity's job first. Confirm the expected list of services for each automation account before setting thresholds.
Enumeration from unseen sources
Alert when listing activity comes from an identity, source address, or client application that has no prior record of performing enumeration against that tenant or account. Pair the identity with the source network range and the user agent field from the cloud audit log, so that a known administrator working from a new location is distinguished from a credential used from an unfamiliar host. Tune the lookback period and maintain a register of approved scanner and backup source addresses. Expect false positives during vendor onboarding and after laptop replacements.
Listing immediately after sign-in
Correlate a new sign-in or session creation with enumeration calls that begin within a few minutes of it, especially when the sign-in used an unfamiliar device, a new location, or a sign-in method the identity does not normally use. This pairing is more specific than either event alone. Tune the correlation window and exclude sign-ins from managed devices that run scheduled inventory jobs. Administrators logging in for routine work will also match, so review the sign-in risk score and MFA result alongside the listing burst.
Discovery bursts across platforms
Look for enumeration bursts that span more than one platform in the same window, such as an identity provider directory query followed by IaaS resource listing and then an office suite or SaaS admin listing. Single-platform bursts are common in ordinary operations, but a sequence that crosses identity, infrastructure and collaboration systems is harder to explain without an attack or an unusual project. Tune by documenting which platform combinations are legitimate for each team, and suppress known migration projects with a fixed end date. Backup jobs and CSPM scanners often touch many platforms, so keep them on an explicit allow list with their own owners recorded.
Known false positive sources
Several common operations produce the same telemetry as T1526 Cloud service discovery. Inventory tools, CSPM scanners, backup and disaster recovery jobs, and asset management connectors all enumerate services on a schedule. Administrators during onboarding or a tenant migration also generate broad listing activity for days. Before tuning, ask each owning team for its schedule, service accounts, source addresses and expected services, then record those in the allow list with a review date. Validate exclusions in the cyber range by replaying the scanner's normal behavior, so that suppressions do not hide real intrusions.
How to validate that the cloud discovery detection actually fires
This sequence proves, in a lab or private range against a non-production tenant, that activity mapped to T1526 Cloud Service Discovery produces alerts that reach the right people within a known time. It ends with a dated list of gaps that feeds the detection engineering backlog.
Agree the validation scope in writing
The detection owner, the cloud platform team and the security operations lead sign a short scope note before any activity runs. The note names the non-production tenant or subscription, the identity providers and SaaS applications in scope, the test accounts used, the time window, and who may stop the exercise. It also states that no production data, customer records or live credentials are involved. The step is done when all three parties have signed and the scope is stored with the detection record.
Map each planned activity to ATT&CK
Build a plan table that lists every activity the emulation will perform, the platform it targets (IaaS, identity provider, office suite or SaaS), and the ATT&CK ID it represents, using T1526 for the parent technique and the relevant sub-technique or related ID where one applies. Each row also names the expected telemetry, such as Cloud Service Enumeration, User Account Metadata or Logon Session Creation, and the data component the detection strategy references. The plan should target the ATT&CK version the team has documented for its detections, because technique definitions can change between releases. The step closes when a reviewer can trace every row to one detection and one data source.
Confirm log ingestion and latency baseline
Before any test activity, the platform team confirms that the cloud audit logs, identity provider sign-in and directory logs, and SaaS audit logs for the test tenant reach the SIEM, such as Wazuh or a Security Onion deployment. They record the ingestion path for each source and measure a baseline delay by generating a harmless marker event and timing its arrival. The baseline becomes the reference for the time-to-alert measurement in later steps. The step is complete when each in-scope source has a documented path and a recorded baseline delay.
Run the scoped emulation in the range
A tester runs the agreed activities from the plan, in the order recorded, from the test accounts and network locations listed in the scope note. The exercise uses lab tooling and a private range only, and the tester logs start and end times for each activity in a shared timeline. Observers in the detection team do not tune rules during the run, so the result reflects the current detection. The step is done when every planned row has a timestamped entry, including any activity that could not be executed and the reason.
Check alert routing to the correct queue
The security operations lead verifies that each expected alert is created, that it is tagged with the ATT&CK ID from the plan, and that it lands in the queue or case type assigned to that platform. Routing tests also confirm that notifications reach the on-call channel and that no alert is silently suppressed by an existing rule or exception. Any alert that appears in the wrong queue is logged as a routing defect, separate from a detection defect. The step closes when every expected alert has a confirmed destination or a logged defect.
Record time to alert and fields present
For each detection, the analyst records the time between the emulated activity and the alert, subtracts the baseline ingestion delay from the earlier step, and notes which fields appear in the alert, such as the acting identity, source address, platform, target service and result. Missing fields are recorded against the data component the detection strategy expects, so the team can see whether the gap is in collection or in parsing. The step produces a table with one row per detection and a completed field checklist. It is done when every row has a time value or an explicit reason for none.
Log gaps into the detection backlog
The detection engineer reviews the results with the operations lead and converts each gap into a backlog item with an owner, the affected ATT&CK ID, the platform, and the evidence from the run. Gap types include no alert, late alert, missing field, wrong queue and noisy alert. Items are ranked by the consequence of a missed detection in the client's environment, not by ease of fix. The step is complete when every gap has a ticket, and the next validation run is scheduled against the same plan to confirm each fix.
Why legitimate inventory activity makes cloud discovery hard to separate from attacks
Most cloud discovery alerts fire on activity that administrators, deployment pipelines and posture tools perform every day. A cloud administrator listing instances, a Terraform or other infrastructure-as-code run refreshing state, a CSPM scanner enumerating resources and an SaaS admin reviewing user lists can each produce enumeration events that look much like an intruder mapping the tenant. The detection design therefore has to start from who or what made the call, not from the API name alone. Before tuning any rule for T1526 Cloud service discovery, document every legitimate source of listing calls in each platform you monitor, including IaaS accounts, the identity provider, the office suite and key SaaS applications.
The first separator is identity type. Human administrators should authenticate through federated single sign-on with multifactor authentication, while automation should run under workload identities such as service principals, instance roles or application accounts with fixed, documented scopes. A listing call from a human identity at an unusual hour is a different signal from the same call made by the pipeline role that always runs at that hour. Next, compare the source network and the user agent or client application. Pipeline runners, CSPM vendors and admin workstations usually egress from known address ranges, so a workload identity that suddenly calls from a residential or unfamiliar address deserves review. Check whether each platform records the source address and client application in its audit logs, and confirm that scope with the vendor, because some SaaS audit trails omit one or both fields.
The second separator is context. Correlate enumeration events with approved change tickets, deployment records and scheduled jobs. A CSPM scan that runs every night at the same time from the same role is expected, and a baseline of its normal volume and resource types lets analysts ignore it while still alerting on new scope, new regions or new service families. Keep the baseline in version control alongside the rule set so that changes are reviewed. Finally, agree on an escalation path for events that match no ticket or schedule. Ask each platform owner which audit log categories are retained, for how long, and whether listing calls appear at the same detail level as write events, because a detection that depends on logs you do not actually receive will fail silently.
Mitigations that reduce what discovery can reveal
Discovery succeeds when an identity can see more than it needs to. The mitigations below narrow that visibility from several directions: who holds accounts, which network paths exist, what gets logged, how systems are configured, what traffic is inspected, and which services are switched on. Each one is mapped in ATT&CK to Discovery techniques, so each can be checked against T1526 Cloud service discovery in your own environment.
Limit account and role scope
User Account Management (M1018) restricts who can create, modify and grant roles in identity platforms and IaaS consoles. A discovering identity can only enumerate services its roles allow it to query, so over-broad read roles such as tenant-wide directory or project-wide inventory access directly widen what T1526 reveals. Review which accounts can list services across subscriptions, projects or tenants, and confirm that service accounts used by automation have no interactive or administrative reach they do not need. Ask your identity team for a current export of role assignments.
Segment cloud control planes
Network Segmentation (M1030) limits which hosts, subnets and management endpoints can reach cloud management APIs and identity services. For T1526, the question is whether a workstation or workload that should not manage cloud resources can still reach the APIs that enumerate them. Map management paths from admin networks, CI runners and developer segments, then confirm that egress rules and private endpoint configurations block unexpected callers. Verify these controls from the segments you intend to restrict, not only from the design document.
Enable and retain audit logs
Audit (M1047) is the mitigation that makes discovery visible at all. Control plane and identity audit logs should record list, describe and get operations across IaaS, identity provider and SaaS administration consoles, with retention long enough for hunts to look back. Confirm that these logs are enabled in every account, tenant and project, that they reach a central store, and that someone has tested a query for enumeration bursts from a single identity. Retention periods should be set against your own policy, so confirm the values with the platform owner.
Harden cloud host configuration
Operating System Configuration (M1028) covers the images and virtual machines that act as jump hosts, CI runners and management workstations. These hosts often hold cloud CLI profiles, cached tokens or instance metadata access, so they are a common source of discovery calls. Standardize builds, restrict which tools are installed on administrative hosts, and limit instance metadata access to the workloads that need it. Review the baseline with your platform team and record exceptions in writing.
Inspect and block suspicious API traffic
Network Intrusion Prevention (M1031) applies to traffic that crosses your network boundary, including outbound calls from workloads to cloud and SaaS endpoints. Signature and behavior rules can flag unusual enumeration patterns, such as a host calling many management endpoints in a short window. Note that much cloud API traffic is encrypted and reaches SaaS endpoints directly, so inspection coverage depends on your proxy, TLS handling and egress design. Confirm coverage with a test from a representative workload before relying on it.
Disable unused cloud features
Disable or Remove Feature or Program (M1042) reduces the number of services and management interfaces an identity can query. Unused IaaS regions, deprecated SaaS admin modules, legacy authentication methods and idle management tools each add surface that discovery can reach. Build an inventory of enabled services per account and tenant, retire those with no owner, and review them on a fixed cadence. Ask your cloud and SaaS administrators which features they can turn off without breaking business workflows.
Triage steps when a cloud discovery alert fires
Start by answering one question: is the identity that ran the enumeration a known, accountable principal? Resolve the identity to a named person or a registered workload, confirm its owner in your identity provider and HR or service catalog records, and check whether that owner expects activity from this account at this time. For cloud service discovery, the alert usually names a user, service principal or role that made many read-only list and describe calls across IaaS, identity and SaaS consoles in a short window. Record the principal, the source address, the client application and the tenant or account it acted in before anyone changes anything. Ask the owner directly through a channel you verify independently of the alert, not through a reply to an email that may have come from the same session.
Next, pull the sign-in and session history for that identity over the period before the alert, not just the minutes around it. Look for new sign-in locations, unfamiliar user agents, sign-ins that required a new device or MFA method, and session creation that does not match the usual pattern for the role. Then compare the services the identity touched with what its role legitimately needs. A developer account that lists IAM policies, directory objects and billing data across several accounts is a stronger signal than one that reads a single resource group it normally uses. If the evidence points to a compromised session, the decision is to contain: revoke the sign-in sessions and refresh tokens, require re-authentication, and rotate any access keys or client secrets the identity holds. If the evidence points to legitimate use, document the reason and move on. Confirm the decision with the cloud and identity owners before disabling a production workload identity, because a containment step can itself cause an outage.
Rehearsing cloud service discovery detection in a private cyber range
Build the IaaS tenant as an isolated project or subscription inside the range, with its own identity store, a small set of compute instances, storage buckets and a logging pipeline that forwards control plane events to the SIEM. The range should mirror the production logging configuration, not an idealized one, because gaps in audit logging are often the finding. The exercise injects enumeration of the control plane through a service principal or user session that is not normally used for that purpose, so the team can test whether the detection relies on the actor's identity, the API call pattern or both.
- Topology: One tenant, two accounts (one administrative, one developer), one sandbox project, and the control plane audit log forwarded to Wazuh or a comparable collector.
- Scripted injects: Ordered listing calls across services, followed by metadata reads on several resources, run at a pace that differs from normal operator behavior.
- Benign noise: Scheduled inventory jobs, a configuration management tool running read-only checks and a developer listing resources after a deployment.
- Good detection: An alert appears within the agreed window, names the calling identity and source address, and separates the scripted enumeration from the scheduled jobs.
- Good response: A ticket is opened with the affected account, the containment decision (disable the session or keep it under watch) is recorded, and the post-exercise review checks whether the API call pattern is documented in the detection content.
Confirm with the cloud provider which control plane events are logged by default, and which require explicit configuration.
Stand up an identity provider in the range with federated sign-on to several SaaS applications, including one with administrative consoles. Discovery against this layer often looks like ordinary browsing of directories, group lists and application catalogs, so the exercise should measure whether the team can separate a user exploring their own access from a session that is enumerating accounts it does not need. Logon session creation and user account authentication events from the identity provider are the core telemetry, and the range should confirm that they carry the client, device and application context needed for triage.
- Topology: An identity provider with two user groups, a privileged group, three federated applications and log forwarding to the SIEM.
- Scripted injects: A session that opens several application consoles in quick succession, followed by directory queries against user and group objects from an unfamiliar client.
- Benign noise: Help desk staff searching for users, single sign-on to the same applications from managed devices and automated provisioning connectors reading directory data.
- Good detection: The alert identifies the user, the federated application set and the device, and it does not fire on routine help desk searches without context.
- Good response: The on-call analyst confirms the identity owner through a second channel, the session is revoked or the account is locked according to the agreed procedure, and the review records whether the revocation reached every federated application.
Check with the identity provider vendor which directory queries are logged, and whether the logs include the application context for each session.
Office suite audit feeds record mailbox, file sharing and tenant configuration activity. Discovery here shows up as broad searches of shared content, enumeration of sites or mail folders and reads of tenant settings that a single user rarely needs. The range should replay a sanitized audit export or a test tenant feed, so the team can judge whether the detection works with the field names, delays and retention the production feed actually has. Audit feeds are often delayed or batched, which makes the alert window a property to measure, not assume.
- Topology: A test tenant or sanitized audit feed, a set of user mailboxes and file sites, and an ingestion path into the SIEM with the same batching behavior as production.
- Scripted injects: A user account that lists sites and shared libraries it has not accessed before, plus reads of tenant configuration pages, spread over a short period.
- Benign noise: Compliance staff running content searches, IT administrators reviewing sharing settings and a backup product enumerating sites.
- Good detection: The alert arrives within the agreed window, even allowing for feed latency, and attributes the activity to the correct user and the correct tenant.
- Good response: The team confirms whether the activity is within a documented investigation, adjusts sharing or access where needed, and records in the review whether the feed latency changed the decision.
Ask the office suite provider for the documented audit delivery latency and retention period for the plan in use, and confirm them in your own tenant before setting the alert window.
Questions SOC leads and detection engineers ask about T1526
How do I tell T1526 cloud service discovery apart from T1538 cloud service dashboard activity?
The two techniques look similar in logs because both involve an identity reaching cloud services, but they differ in intent and in what the activity touches. T1526 covers enumeration of which services exist in the environment, such as listing subscriptions, projects, workloads or enabled SaaS applications through API or management calls. T1538 covers a user or session opening a cloud service dashboard or console and browsing it. In practice, correlate Cloud Service Enumeration events with Logon Session Creation and User Account Authentication for the same identity within a short window, then check whether the pattern is many list or describe calls across services (closer to T1526) or interactive console sessions (closer to T1538). Confirm in your environment which event names your providers emit for each, since naming differs by platform and the mapping should be checked against the ATT&CK version you target.
Which logs should I confirm first on each cloud and SaaS platform?
Start with the audit trail that records control-plane and directory activity, because T1526 usually shows up as enumeration calls rather than as malware. For IaaS, confirm that management-plane API logging is enabled in every account, region and subscription, including the logs that record list and describe operations. For the identity provider, confirm sign-in and directory audit logs are forwarded and retained. For office suites and SaaS, confirm admin and unified audit logs are on, since some of them are off or limited by default and need an explicit setting. Check the forwarding path into your SIEM (for example Wazuh or a Security Onion pipeline) and test that a known benign list call appears there with the expected identity, source address and timestamp. Retention and completeness vary by provider and plan, so confirm the exact retention and log availability with each vendor before you write detection thresholds.
How should I handle naming differences across multiple cloud providers?
Normalize events into one schema before writing shared rules. Map each provider's operation name, such as a list or describe call, to a common field like enumeration action and service category, and keep the original provider field so analysts can pivot back to the raw event. Maintain the mapping as a versioned file in your detection repository, with one entry per provider and per log source, and review it whenever a provider changes its audit schema. Tag each rule with the ATT&CK version it was written against, because releases can rename or revoke techniques and detection strategies. Expect that some providers will not expose an equivalent event for every action, so document those gaps as known coverage holes rather than assuming parity. Validate the normalized rule by replaying a sample from each provider in a cyber range before it reaches production.
How often should I re-check T1526 mappings after ATT&CK releases?
Re-check mappings on each ATT&CK release, and also when a provider changes its logging or API behavior, because the second trigger is often the one that breaks a rule. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, per MITRE's updates pages, and they can rename, deprecate or revoke techniques and move detections to detection strategies and analytics. Pull the STIX bundle for the version you target, diff the T1526 entry and its data component references, and update your rule metadata. Assign an owner for this review and record the date and version in your change log. The effort depends on how many platforms and rules you maintain, so ask any implementation partner to quote the review as a recurring task with a defined scope.
How can I test T1526 detections without affecting production?
Run the tests in a private cyber range or a separate, non-production account, project or tenant that mirrors your logging configuration. Use a dedicated test identity with least privilege, scope the test to a named time window, and agree the window and the stop conditions with the owners of the affected platforms before you start. Describe the expected enumeration activity as a written test plan, mapped to the ATT&CK version you target, and record for each step the expected log events, the expected detection and the expected alert. Check that alerts reach the right queue, that the enrichment fields are populated and that the case is closed with evidence. Keep the test identity and its logs separate from production data, and confirm with your provider's terms and your internal policy that the test activity is permitted. DeployOpen can plan and run this kind of exercise in a private cyber range as a fixed-scope engagement with written deliverables.
What does it cost to build and maintain T1526 detection, and what drives it?
The cost has four main parts: log source configuration across each cloud, identity and SaaS platform, normalization and rule engineering in your SIEM, testing in a range, and the recurring review after ATT&CK and provider changes. Who is paid depends on whether your staff do the work or an implementation partner does it under a written scope. One-time costs include logging setup, schema mapping and the first test plan. Recurring costs include rule upkeep, log source health checks, retention storage and periodic exercises. Costs rise with the number of accounts, regions, SaaS tenants and log sources, and with the amount of cross-platform correlation required. No vendor price is given here, so ask any provider or partner for a quote that separates one-time setup, recurring operation and the cost of storage, and that states the scope of platforms and rules included.
Can my team build T1526 detection in-house, or do we need an outside partner?
Many SOC teams can build and run this detection in-house if they already operate a SIEM, own cloud audit logging and have engineers who read provider APIs. The work becomes harder when you run several clouds and SaaS tenants, when logging is inconsistent across accounts, or when no one owns the ATT&CK review cycle. Assess this honestly by listing your current log sources per platform, the number of people who can write and test rules, and whether you have a non-production range for testing. An outside partner is useful for fixed-scope work such as logging configuration, normalization, range-based validation and documentation, and for ongoing testing under a retainer. Make the division of responsibility explicit in writing so that ownership of rules, evidence and alerts stays with your team.
How DeployOpen builds cloud discovery detections and range exercises
DeployOpen starts every cloud discovery detection engagement with a written scope that names the cloud and identity platforms in use, such as the IaaS accounts, the identity provider tenant, and the office suite or SaaS applications that record enumeration activity. The scope also states which telemetry sources the client can actually forward, for example cloud service enumeration logs, user account metadata and logon session creation records, and which ATT&CK version the detection mapping will target. Because ATT&CK releases can rename or deprecate content, the mapping is pinned to a named version, and the client confirms in writing which version their detection team will maintain. Quotes follow from this written scope, so the reader should expect the platform list, log sources and deliverables to be stated before any work begins.
Detection content is then built as open-source rules and pipeline configuration that the client's own team can read, run and change. For T1526, that typically means rules for Wazuh, Sigma or Security Onion that flag unusual volumes of list and describe calls from a single identity, enumeration from service accounts that normally perform no discovery, or first-time access to administrative consoles from unfamiliar sessions. Each rule is written against the stated ATT&CK version, documented with its data source assumptions, and tested against sample events from the client's own tenants where the client permits. Where a required log source is not enabled, the handover notes say so plainly and name the setting the client must confirm with its cloud or identity provider.
DeployOpen then runs purple team exercises in a private cyber range that mirrors the client's cloud and identity configuration, so that the detection is rehearsed before it is trusted in production. The exercise records which discovery actions were visible, which were missed, and how long the response workflow took to reach a decision, with the results kept as evidence. The handover includes tuning notes covering expected false positives from automation and backup tooling, threshold rationale, and a list of open items for the client's detection team. Those artifacts can also support compliance readiness work, although independent auditors and certification bodies, not DeployOpen, decide whether any control is met.
