Azure security assessment

Why organizations commission an Azure security assessment

Most organizations commission an Azure security assessment because someone outside the platform team needs evidence about Azure. That someone may be a compliance assessor, a customer running a security review, an insurer setting cover terms, a launch review, or a buyer in due diligence. An Azure security assessment is a configuration review and targeted testing of your subscriptions and the workloads connected to Entra ID, measured against the CIS Microsoft Azure Foundations Benchmark. The output is a set of findings you can act on, not a generic scan export, and it shows how your settings compare with a published benchmark that auditors and customers already recognize. The assessment concentrates on four risk categories where Azure environments most often drift. The first is over-broad role assignments, including standing Owner or Contributor rights at subscription or management group scope, guest accounts with access they no longer need, and service principals with more permission than their workload uses. The second is exposed network paths, such as management ports reachable from the internet, permissive network security group rules, and public endpoints on services that should be private. The third is storage exposure, meaning storage accounts that allow public access or weak transport and key controls. The fourth is weak logging, where activity logs, diagnostic settings or retention are missing for the resources that matter most. Each category maps to specific controls in the benchmark, so a finding can be traced to the recommendation it breaches. The split of responsibility shapes what the assessment can and cannot prove. Microsoft secures the Azure platform itself, including the physical infrastructure and the services it operates. Your organization secures how that platform is configured, who holds identities and with what rights, and where data is stored and protected. Before you commission work, confirm with your provider and with Microsoft's current testing rules which of your services and tests fall within your own tenant and subscriptions. Then decide who owns each remediation, since most findings sit with your cloud, identity and security teams rather than with the testers.

What an Azure security assessment can cover

Before any testing starts, the scope has to be fixed in writing. The decisions below determine what gets reviewed, what gets tested actively, and whose permission is needed. Each one changes the cost, duration and evidence the client receives.

Subscriptions and management groups

Decide which subscriptions, management groups and resource groups fall inside the review. A management group can hold subscriptions owned by different teams or business units, so confirm that every subscription in scope is owned and controlled by the client. Subscriptions owned by a third party or a subsidiary need their own written authority before they are added. Record the exclusions as deliberately as the inclusions.

Tenant and Entra ID objects

Identity scope covers the Entra ID tenant, its users, groups, service principals, app registrations and managed identities that hold rights over the in-scope subscriptions. Agree whether the review reads tenant-wide conditional access and directory roles or only the roles that reach Azure resources. Confirm who can grant the reviewer read access, since tenant-level changes often sit with a different team than the subscriptions.

Workloads and data stores

List the workloads that matter most: virtual machines, App Service, AKS clusters, Azure Functions, storage accounts, databases and key vaults. Ask for an inventory export and compare it with what the cloud team believes is running. Tests against an unlisted workload are out of scope, so an incomplete inventory produces an incomplete report.

Configuration review or active testing

Decide whether the engagement reads configuration only, or also tests exposed services actively. A configuration review checks settings against the CIS Microsoft Azure Foundations Benchmark and the client's own baseline. Active testing adds probing of internet-facing endpoints and authenticated checks inside workloads, and needs explicit approval for each service and technique. Many clients start with configuration review and add active testing once the baseline is clean.

Rules of engagement and sign-off

Name the client signatory who authorizes the test in writing, usually someone with authority over the subscriptions in scope. The rules of engagement should state permitted techniques, testing windows, source IP addresses, escalation contacts and stop conditions. Microsoft's cloud penetration testing rules prohibit DDoS under all circumstances, phishing of Microsoft staff, access to tenants the tester does not own and network-intensive fuzzing, so those limits belong in the document too. Confirm the current Microsoft rules before drafting.

Vulnerabilities in Microsoft services

Findings in the Azure platform itself are a different category from misconfigurations in the client's own resources. Under Microsoft's rules, vulnerabilities found in Microsoft services must be reported to MSRC rather than exploited or published. The scope should state that the tester reports platform issues through that channel and that the client's findings cover only its own configuration. This keeps the engagement within the rules and avoids ambiguous ownership of results.

How the assessment runs, phase by phase

The sequence moves from agreed rules of engagement to a read-only review, targeted testing where it was approved, validated findings and a retest, so each phase produces evidence the next one builds on. Timelines for each phase are set in the written scope, not assumed here.

Agree scope and written rules of engagement
Your team and DeployOpen define which subscriptions, management groups, tenants and Entra ID-connected workloads are in scope, who the named contacts are, and which test types are allowed. We check the request against Microsoft's Cloud penetration testing rules of engagement, which prohibit DDoS under all circumstances, phishing or social engineering of Microsoft employees, testing of tenants or data the tester does not own, and network-intensive fuzzing. Any test that falls outside those rules is removed or redesigned before work starts. The step closes when both parties sign a scope document that lists in-scope resources, excluded resources, permitted test types and the schedule to confirm in writing.
Collect read-only configuration evidence
The reviewer gathers configuration data through read-only access granted for the review, such as reader-level roles and exports of policy, role assignment, network and logging settings. No changes are made to production resources in this phase. Access is granted through the least privileged role that allows the review, and the access itself is logged so you can see what the reviewer viewed. The step closes when the evidence inventory lists each subscription and resource type reviewed, with the collection date and the access used.
Map configuration against CIS controls
Each collected setting is compared with the relevant section of the CIS Microsoft Azure Foundations Benchmark at version 6.0.0. Sections covering identity and access, security center settings, networking, storage accounts, database services and logging and monitoring are checked against your configuration, and each control is marked as passed, failed, not applicable or needing manual confirmation. Where the benchmark does not fit your architecture, the reviewer records the deviation and the reason rather than silently skipping the control. The step closes when every in-scope control has a recorded status and a reference to the evidence behind it.
Test exposed endpoints and identities as agreed
Targeted testing covers only the endpoints, identities and workloads named in the scope, such as internet-facing services, API endpoints, or privilege paths between identities and roles. Testing is limited to the agreed techniques, and anything involving denial of service, flooding or fuzzing at network scale is excluded. Where workloads reach cloud metadata endpoints, the reviewer checks whether server-side request forgery could expose credentials, since that weakness category is listed as API7:2023 in the OWASP API Security Top 10. The step closes when each test has a recorded objective, the result, and the request and response evidence needed to reproduce the observation.
Validate and rate each finding
Before any finding reaches the report, a second reviewer repeats the check or confirms the evidence, removes false positives and checks that the affected resource belongs to your tenant. Each validated finding is rated against the impact on your environment and the likelihood of exploitation, and linked to the CIS control it relates to where one applies. Findings that touch a Microsoft service rather than your configuration are routed to the provider under the rules of engagement, not written up as your defects. The step closes when every finding has a status, a rating and a short description of the conditions needed for it to occur.
Deliver the report and remediation plan
The report sets out scope, method, the CIS control mapping, validated findings with evidence and recommended remediation for each one. It separates configuration findings from testing observations so your auditor or customer can trace each claim to its source. A readout meeting walks engineering and risk owners through the findings and agrees which items will be fixed and by whom. DeployOpen prepares the evidence and does not issue an audit opinion or certification. The step closes when the report is accepted, and the agreed remediation owners and fix priorities are recorded in writing.
Retest the agreed findings
After your team applies fixes, the reviewer re-checks each finding listed in the agreed retest scope, using the same evidence method as the original test so results are comparable. A finding is closed only when the retest shows the condition is gone, and a finding that remains open is recorded with the reason. Retest scope, any extra cost and the window for it are confirmed in the written scope before the original engagement starts. The step closes when a retest report lists every retested finding as closed or open, with the evidence for each status.

Which Azure weaknesses the assessment looks for

This table maps each Azure weakness category the assessment checks against the CIS Microsoft Azure Foundations Benchmark to what it looks like in the environment and why it matters to an auditor or an attacker. Read each row as a review question: if the answer is yes in your tenant or subscriptions, the finding is likely to appear in the report and the remediation plan.

Weakness category	What it looks like in Azure	Why it matters to an auditor or attacker
Privileged role assignments	Owner or User Access Administrator roles assigned broadly at subscription or management group scope, or many standing assignments with no expiry	Excess privilege lets a compromised identity change any resource in scope, and auditors expect least privilege and periodic access reviews
Guest and external identity exposure	Guest accounts holding roles on production subscriptions, stale B2B invitations, or external collaboration settings that are wider than the business needs	External identities are often less controlled than employees, so an unused guest with a privileged role is an easy path into the tenant
Conditional Access and MFA gaps	Administrator accounts or privileged roles not covered by Conditional Access policies that require phishing-resistant or strong MFA, or policies excluding break-glass or service accounts without review	Administrator sign-ins without strong MFA are a common route to full control, and assessors check that policy covers every privileged role
Public network exposure of data services	Storage accounts, SQL databases or other data services reachable from the public internet without private endpoints, firewall restrictions or virtual network rules	Exposed data stores put confidential records within reach of anyone who obtains a valid credential, and they are a frequent audit finding
Broad inbound network security group rules	NSG rules allowing any source or wide port ranges to management ports, databases or internal services, often added during troubleshooting and never removed	Broad inbound rules shrink the attack surface an attacker must cross and show assessors that network segmentation is not enforced as documented
Unencrypted or publicly reachable storage	Storage accounts with anonymous blob access enabled, secure transfer not required, or customer-managed key settings absent where the data classification calls for them	Anonymous or unencrypted storage can expose files directly, and the configuration is easy for an assessor to verify against the benchmark
Disabled or incomplete logging	Activity log export missing, diagnostic settings absent on key resources, short retention, or alerts not configured for role changes and policy changes	Without logs, a breach or privilege change cannot be reconstructed, and auditors ask for evidence that the logs exist and are retained
Server-side request forgery to metadata	Web applications or APIs running on Azure that fetch user-supplied URLs and can reach the instance metadata service at 169.254.169.254, exposing managed identity tokens	A successful request can expose managed identity credentials, so the path turns an application flaw into cloud-level access and is tested within the scope of the API review

What Microsoft's rules of engagement allow and prohibit

Microsoft's Cloud penetration testing rules of engagement set the outer boundary for any Azure test, and they are narrower than many buyers expect. Microsoft prohibits denial-of-service and DDoS attacks under all circumstances, so no load test, stress test or availability test against Microsoft-operated services is permitted. The rules also prohibit phishing or social engineering of Microsoft employees, accessing data or tenants the tester does not own, and network-intensive fuzzing. For a buyer, the practical consequence is that the test scope must name the client's own subscriptions, resource groups, identities and workloads, and the statement of work should say so in terms a third party can check.

Those limits shape scope decisions well before testing starts. Any request to exercise a load balancer, application gateway or public endpoint at volume should be treated as a separate question to settle in writing, with the provider confirming whether the activity is permitted under Microsoft's rules and whether the client's own service agreements allow it. Tests that touch shared identity infrastructure, such as tenant-wide Entra ID configuration, need the same care: the client's own tenant and directory objects are in scope, but anything that reaches another organization's tenant is not. Ask the provider to list every subscription, tenant and resource type in the test plan, and to state which items are excluded.

The rules also set the response to platform flaws. If a tester suspects a vulnerability in a Microsoft service rather than in the client's configuration, the correct step is to stop, document what was observed without exploiting it further, and report it to Microsoft through the Microsoft Security Response Center. The Microsoft Cloud penetration testing rules of engagement page is the next read for the full list. Before signing, confirm with the provider how they handle this path, who is notified inside the client organization, and how findings that fall in Microsoft's responsibility are separated from findings the client must fix.

What drives the cost and duration of an Azure assessment

This table compares the components of an Azure assessment that set its price and length, and says whether each one is paid once or recurs. Use it to check that a written quote states the same counts and depth you expect, because a quote that leaves these out cannot be compared with another. The main takeaway is that subscription count, identity sources and internet exposure usually matter more than the number of resources.

Cost component	What it covers	One-time or recurring	What to ask for in a quote
Subscriptions and management groups	Number of subscriptions in scope and how they sit under management groups, which affects how much policy inheritance and role assignment must be traced	One-time for the assessment, recurring if re-assessed	Named list of subscriptions and management groups, and whether inherited policy is reviewed
Entra ID tenants and identity sources	Number of tenants, hybrid sync with on-premises directories, guest access and conditional access policies that affect Azure role assignments	One-time, with a recurring review of access rights	Tenant count, sync topology, whether conditional access and privileged role settings are in scope
Internet-exposed workloads and services	Public IP addresses, public endpoints, App Service, API Management, load balancers and storage endpoints reachable from outside the network	One-time; exposure changes need re-review	Inventory of externally reachable services and whether each one is tested actively or only reviewed
Depth: configuration review or active testing	A configuration review checks settings against the CIS Microsoft Azure Foundations Benchmark; active testing adds attempts to exploit weaknesses within Microsoft's rules of engagement	One-time; active testing adds effort and scheduling	Whether the quote is configuration review only, active testing, or both, with the rules of engagement stated
Number of environments	Production, staging and development subscriptions, and whether each is assessed separately or sampled against a common baseline	One-time per environment assessed	Environment list and whether non-production is sampled or fully reviewed
Reporting depth	Level of evidence per finding, mapping to CIS control IDs, remediation guidance and any evidence pack for an auditor or customer	One-time deliverable	Sample report, mapping format, and whether evidence exports are included
Retest	Verification that remediated findings are closed, usually after the client fixes role assignments, network rules or logging settings	One-time per retest round	Number of retest rounds included, and the time window for requesting one
Continuous monitoring retainer	Periodic re-review of role assignments, network exposure and diagnostic settings as the Azure estate changes	Recurring	Review frequency, scope of subscriptions covered, and how findings are reported between cycles

What you receive and whether it satisfies an auditor or customer

An Azure security assessment produces a set of linked records rather than a single verdict. Each part answers a different question for your auditor, customer or board, so confirm early which format each one accepts. The cards below describe what the package contains and what to check before you accept it.

Scope and rules of engagement record

This record lists the subscriptions, tenants, Entra ID components and workloads in scope, along with the testing activities agreed for each. It also states which activities Microsoft's rules of engagement prohibit, such as DDoS, phishing of Microsoft staff and network-intensive fuzzing, and confirms that no tenant outside your ownership was touched. Check that the subscription IDs match your own inventory, because a scope that omits a subscription will not support a claim about it.

CIS control mapping with pass or fail

Each applicable recommendation in the CIS Microsoft Azure Foundations Benchmark is listed with its control ID, a pass or fail status and the evidence used to decide it. Controls that do not apply to your environment should be marked not applicable with a reason, not silently dropped. Ask which benchmark version the mapping uses and whether it covers Entra ID-connected controls as well as Azure resource controls.

Findings with severity and evidence

Each finding describes the weakness, the affected resource, the severity rating and the evidence that supports it, such as configuration exports, role assignment listings or log queries. Findings should describe the weakness category and its impact without step-by-step exploitation. Ask how severity is assigned and whether your risk team can adjust ratings with documented reasoning.

Remediation guidance and retest results

Remediation guidance names the change to make, the owner and the verification step for each finding, such as an updated role assignment or a restricted storage network rule. Retesting then re-checks each finding and records whether it is closed, partly closed or still open. Confirm whether retesting is included in the original fee or quoted separately, and how long the retest window stays open.

Letter describing the work performed

The letter from DeployOpen describes the scope, the methods used, the dates of work and the deliverables produced. It is not an audit report, attestation or certification, and it does not state that your environment is compliant. An independent auditor or certification body issues those. Give the letter to your auditor as evidence of the testing performed, and confirm whether they want it on your letterhead or ours.

Confirming the format your auditor accepts

Before the work starts, ask your auditor or customer which format they accept, which sections they need, and whether they require a named tester or a particular methodology statement. Some reviewers want the CIS mapping as a spreadsheet, others want a narrative report with an executive summary. Record the agreed format in the written scope so the deliverables match what the reviewer will ask for.

How the assessment differs across Azure architectures

A single subscription hosting App Service and Azure SQL is the simplest shape to assess, and the scope is usually fixed by one subscription boundary. The review concentrates on how the web tier reaches the database, who holds roles on the subscription and resource group, and whether storage and logging are configured to the benchmark's expectations. Because there is one control plane, the evidence set is compact.

Role assignments: Owner and Contributor grants at subscription level, and whether application identities hold broader rights than their function requires.
App Service exposure: HTTPS-only settings, minimum TLS version, public network access and whether managed identities replace stored connection secrets.
SQL server settings: Firewall rules, Entra ID administrator configuration, auditing and whether public endpoints are reachable from the internet.
Storage and logging: Public blob access, storage account network rules and whether activity logs and diagnostic settings are retained and sent to a central workspace.

Confirm with the client which subscription IDs are in scope and who owns each resource group, so testing stays within subscriptions the client controls.

What your team prepares before testing starts

Before any Azure testing begins, your team needs to settle who can see what and who can say yes. Start with read-only reviewer roles in each subscription in scope, assigned to the people doing the configuration review, usually with the built-in Reader role at subscription or management group level. Agree in writing who approves these assignments, how long they last, and how they are removed at the end of the engagement. Each subscription also needs a named contact with authority to make decisions about that subscription, plus a backup, so questions about a role assignment or a storage account can be answered within the working day rather than held until the next status call.

Next, agree the list of exposed endpoints and the test windows. Record public IP addresses, Application Gateway or Front Door endpoints, App Service hostnames and any API Management gateways that are reachable from the internet, and note which of them belong to production. Confirm the windows in which active testing may run and who on your side monitors them. If production monitoring or a major release is sensitive during the engagement, agree a change freeze with the operations team so that configuration changes do not muddy findings or trigger alerts that the testers cannot explain. Any active testing against production resources requires written approval from your organization, and that approval should name the resources, the window and the individual who gives it. Ask who in your organization may approve active tests and confirm that person is reachable during the window.

Finally, gather what already exists. Provide any internal baseline, existing CIS Microsoft Azure Foundations Benchmark assessment, Microsoft Defender for Cloud secure score history, policy initiatives and exception registers, so the review can separate known and accepted deviations from new findings. Export the logging and diagnostic settings as they stand, including activity log retention, diagnostic settings on key resources, and the Log Analytics workspaces that receive them. Capturing this baseline before testing starts lets the team show later whether a finding was present on day one or was introduced during the engagement. Confirm with your provider which CIS benchmark version the review will map to, since the version in use determines the control IDs your report will reference.

What to check when choosing an Azure assessment provider

Azure assessments vary widely in depth, access and independence, and the provider you pick sets the quality of the findings. The cards below cover the questions worth putting in writing before a scope is signed. Each one tests whether the provider can explain its method, handle your tenant safely and report in terms your auditor or customer will accept.

Azure and Entra ID experience

Ask for named evidence that the team has assessed Azure subscriptions and Entra ID tenants, not only on-premises Active Directory or generic cloud work. Check whether they can explain how management groups, subscription inheritance and conditional access policies interact, and whether they review Entra ID roles and app registrations as part of the scope. Ask who will do the hands-on work and how their Azure experience is verified.

Mapping to CIS Azure controls

Ask how each finding is linked to a control in the CIS Microsoft Azure Foundations Benchmark, currently version 6.0.0, by control ID and title. A good provider states which controls were tested, which were checked manually, and which were not in scope. Ask for the mapping format in the sample report so your team can track remediation against the benchmark without re-reading every finding.

Read-only access and credential handling

Ask how the provider will be granted access to your tenant, which roles it will hold, and whether those roles are read-only for the configuration review. Confirm where credentials are stored, who can use them, how long they last and how they are removed at the end. Ask for written confirmation that no changes are made to production resources unless you approve a specific test in advance.

Adherence to Microsoft's rules

Ask the provider to confirm in writing that its testing follows Microsoft's Cloud penetration testing rules of engagement. Those rules prohibit DDoS under all circumstances, phishing or social engineering of Microsoft employees, access to data or tenants the tester does not own, and network-intensive fuzzing. Ask how the team handles any vulnerability it finds in a Microsoft service, since those must be reported to MSRC.

Sample report and retest policy

Request a redacted sample report and check that it names the affected resource, the evidence, the risk rating, the remediation steps and the benchmark control. Ask whether retesting of closed findings is included in the fixed price or billed separately, how long after the report it is available, and whether the retest result is recorded in a separate document. A clear retest policy shows whether the provider expects findings to be closed.

Insurance, confidentiality and independence

Ask for proof of professional indemnity and liability cover, the confidentiality terms that govern tenant data and findings, and where the data is stored. Also ask whether the provider is independent of the team that will remediate the findings. If the same firm designs, builds and then validates the fix, the assessment loses much of its value, so separate those roles in the contract where you can.

Azure security assessment questions buyers ask

How much does an Azure security assessment cost?

The cost depends on the scope agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that scope. The main cost drivers are the number of subscriptions and management groups in scope, the number of Entra ID tenants and connected workloads, the depth of role assignment and network review, and whether the work is a configuration review against the CIS Microsoft Azure Foundations Benchmark only or includes hands-on testing of exposed services. Assessments are typically one-time engagements, while retesting and continuous testing are usually recurring retainers. When requesting a quote, ask for the scope list by subscription, the deliverables, the retest terms and which items are excluded.

How long does an Azure security assessment take?

The timeline is set mainly by how many subscriptions, tenants and workloads are in scope and how quickly the client's team can provide access and answer questions. Configuration review against the CIS benchmark usually moves faster than penetration testing of exposed services, because testing needs agreed windows, a defined list of targets and time to validate findings. Environments with many legacy subscriptions, inconsistent naming or unmanaged role assignments take longer to map. Ask for the planned phases, the dependencies on your team and the date by which the written report and any retest are due.

What does our team need to provide before an Azure assessment?

Your team needs to provide an authoritative list of subscriptions, management groups and Entra ID tenants in scope, plus named owners who can confirm which resources belong to the client. Read-only access for the reviewers is typically required, along with documentation of network design, logging and monitoring setup, and any existing policy or governance baselines. For any testing of live services, you need written authorization from the subscription owner, agreed test windows and a named contact for stopping tests. Confirm the exact access model, approval process and data handling rules with DeployOpen during scoping, since these depend on your environment.

Can our own team run the CIS Azure checks without a provider?

Yes. The CIS Microsoft Azure Foundations Benchmark is published by CIS, and CIS Benchmarks are freely available in PDF for non-commercial use, so an internal team can work through the controls, check configurations and record results. The gap an external assessment fills is independence, consistent interpretation of each recommendation against your architecture, validation of how role assignments and network paths combine, and testing of what the configuration review cannot show. Many organizations run internal checks regularly and commission an external assessment when an auditor, customer or board requires independent evidence. Check the current benchmark version with CIS before you start, since your internal checklist should match it.

Do we need to notify Microsoft before testing our Azure environment?

Microsoft's Cloud penetration testing rules of engagement govern tests of Microsoft cloud services, and they prohibit DDoS attacks under all circumstances, phishing or social engineering of Microsoft employees, accessing data or tenants the tester does not own, and network-intensive fuzzing. They also require that vulnerabilities found in Microsoft services be reported to MSRC. Read the current rules directly from Microsoft before scoping, and confirm with your provider which activities need any notice or approval under those rules. Any test must stay within resources and tenants your organization owns, and the scope document should name them explicitly.

Will an Azure assessment letter satisfy our auditor?

DeployOpen does not issue audit reports, attestations or certifications. An assessment report is evidence that independent testing took place, and it can support a compliance assessment, but the auditor or certification body decides whether it meets the requirement. Ask your auditor early which evidence they expect, such as scope definition, methodology, dated findings, remediation records and retest results. Confirm whether they need the CIS benchmark version and the tested control set referenced in the report, and agree the report format in the statement of work.

How is retesting priced after an Azure assessment?

Retesting is usually priced separately from the original assessment, and the cost depends on how many findings need verification, how many subscriptions or workloads were changed, and whether the retest repeats configuration review or only checks specific items. Fixed-scope engagements typically define retest coverage in the original statement of work, which avoids surprises. Ask whether retesting is included in the quote, how many retest rounds are covered, how long after delivery the retest window remains open, and whether an ongoing retainer for continuous review would be more suitable if your Azure estate changes often.

How DeployOpen scopes, tests, reports and retests Azure work

DeployOpen approaches Azure security assessment as a fixed-scope engagement: subscriptions, Entra ID-connected workloads and the CIS Microsoft Azure Foundations Benchmark are agreed in writing before any testing starts. Findings are documented so your team, your auditor or your customer can follow each item from evidence to fix.

How we scope

Confirm which subscriptions, management groups and Entra ID-connected workloads are in the written scope.
Agree the benchmark version and control areas, such as role assignments, network exposure, storage and logging.
Record which tests need Microsoft's cloud penetration testing rules of engagement reviewed before work begins.

How we build

Review configuration evidence for role assignments, network rules, storage access and diagnostic logging settings.
Test exposed services within Microsoft's rules, excluding DDoS, phishing of Microsoft staff and network-intensive fuzzing.
Map each finding to the relevant CIS control and to the affected subscription, resource and owner.

How we hand over

Deliver a written report with reproducible evidence, severity, affected resources and prioritized remediation steps.
Walk through findings with engineering and security leads so fixes can be assigned and tracked.
Route any vulnerability found in a Microsoft service to MSRC, as the rules of engagement require.

How we support

Retest agreed findings after fixes, and record which items are closed, open or accepted as risk.
Ask whether ongoing review, periodic re-assessment or continuous testing fits your change cadence, available as a retainer.
Confirm with your auditor or customer which evidence format and retest scope they expect before the engagement starts.