AWS security assessment and penetration testing

Why an AWS security assessment is commissioned and what it covers

An AWS security assessment is a structured review of how your AWS accounts are configured, combined with penetration testing of the services exposed from them. It is usually commissioned because a compliance framework, a customer security questionnaire, a product launch, an insurer or an acquirer asks for evidence that the cloud environment has been checked by someone other than the team that built it. The assessment covers identity and access management, network exposure, storage, and logging and monitoring, and it measures the configuration against the CIS Amazon Web Services Foundations Benchmark, currently version 7.1.0 according to CIS. Configuration review tells you what is set up wrongly; penetration testing shows which of those weaknesses an attacker could actually chain together.

The shared responsibility model sets the boundary for every finding. AWS secures the cloud, meaning the infrastructure that runs its services, and the customer secures what is placed in the cloud, which depends on the services chosen and includes data, operating systems, firewall rules and identity settings. Most findings in a typical assessment therefore sit in the customer's domain: an over-broad IAM role, a bucket that is readable from outside the intended audience, a security group open wider than the workload needs, or CloudTrail logging that is off in a region. Confirm with AWS which of your services fall under customer configuration for the controls your auditor will ask about, since responsibility differs by service. The AWS shared responsibility model page is the reference to check against.

Before work starts, agree the account boundary, the services in scope and the testing methods in writing. AWS allows you to test a listed set of services without prior approval, including EC2, RDS and Aurora, CloudFront, API Gateway, Lambda, ECS and Fargate, but it prohibits denial of service, port or request flooding and S3 bucket takeover, and it requires advance notice for simulated events such as red team exercises. Any test that includes command and control needs prior AWS approval. DeployOpen prepares systems, controls and evidence for your assessment and produces findings and remediation guidance, but it does not issue audit reports, attestations or certifications; your independent auditor or certification body makes that determination. Ask any provider to confirm which of these outputs they deliver.

What can be in scope for an AWS assessment

Scope decides what the assessor may touch, what the report can speak to, and whether AWS approval is needed before work starts. Most of these choices are made together in the written scope, so agree them with the assessment provider before any testing begins.

Accounts and regions

Name every AWS account, organizational unit and region in scope, and state which ones are excluded. Testing must stay within resources the client owns, so shared services, third-party accounts and accounts owned by a managed service provider need explicit written consent from their owners. Confirm which regions hold production data, because a clean scan of one region can hide exposure in another. Ask the provider how it will verify account ownership before testing starts.

Services on the no-approval list

AWS lets customers test a listed set of services without prior approval, including EC2, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda, ECS, Fargate and Transit Gateway. Services outside that list may still be in scope, but the scope document should say how each one will be tested and whether AWS notice or approval is needed. Map each in-scope service to its owner and its data classification so findings can be prioritized.

Configuration review scope

Decide whether the engagement includes a configuration review of IAM, network exposure, storage, logging and the CIS AWS Foundations Benchmark, alongside or instead of penetration testing. A review reads settings and policies without sending attack traffic, so it can cover accounts that cannot be tested live. Confirm which benchmark version the review will map to, and ask for a control-by-control result rather than a pass or fail summary.

Command and control testing

Any test that includes command and control infrastructure needs prior AWS approval, and the request must be submitted before the test is planned in detail. Simulated events such as red team exercises, simulated phishing and malware testing require a request at least 2 weeks ahead, according to AWS policy. Decide early whether the engagement is a simple penetration test or an adversary simulation, because the approval path and lead time differ.

Rules of engagement and prohibited activities

AWS prohibits DNS zone walking, hijacking or pharming through Route 53, denial of service, port or request flooding, and S3 bucket or subdomain takeover in customer testing. The rules of engagement should list these prohibitions, the permitted test windows, the source addresses testers will use, and the escalation contact if a test affects production. Ask the provider to confirm in writing that it will follow these limits and the client's own testing terms.

Testing limits for data and other tenants

Agree how the team will handle sensitive data it encounters, such as customer records reached through a storage bucket or a database. Testers should prove access with the least data necessary and must not pull, copy or retain records beyond what the report needs. Scope should also exclude any action that would reach another tenant or a third party's systems, including cross-account paths reached through trust relationships.

How an AWS engagement runs from scoping to retest

The sequence moves from a written account scope and AWS policy check through configuration review and targeted testing to a report and a retest, so each phase produces evidence the next one builds on. Each step closes with a defined output that the client can review and approve before work continues.

Agree the written scope and account list
The client and DeployOpen agree in writing which AWS accounts, regions, services and applications are in scope, and which are explicitly excluded. The account list names the owner of each account and confirms that the client has authority to test every account listed. Shared, third-party or subsidiary accounts are either confirmed in writing or removed. The step closes when the signed scope document lists every account ID, the in-scope services and the agreed testing windows, with no open items on ownership.
Check rules of engagement against the AWS policy
DeployOpen maps each planned activity against the AWS penetration testing policy. Services on AWS's no-approval list, such as EC2, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda, ECS, Fargate and Transit Gateway, can be tested without prior approval. Anything that includes command and control, simulated phishing, malware testing, red or purple team activity, or DDoS simulation is flagged for prior approval or excluded. Prohibited activities such as DNS zone walking, denial of service, request flooding and S3 bucket or subdomain takeover are removed from the plan. The output is a rules of engagement document that the client signs off, with any approval requests logged with a clear owner.
Collect account context and access for review
The client provides read-only access to the in-scope accounts, typically through a dedicated audit role, and confirms logging, identity and network configuration sources. DeployOpen records the account configuration baseline, including the services in use, organization structure and any guardrails already in place. Client staff confirm which services are business critical so that the review can focus on them. The step is complete when access is verified, the baseline is captured, and the client has confirmed that no production changes will be made during the review.
Run read-only configuration review against CIS
DeployOpen checks the configuration against the CIS Amazon Web Services Foundations Benchmark at version 7.1.0, covering identity and access management, logging, monitoring, networking and storage controls. The review is read-only and records the state of each control as passing, failing, not applicable or requiring client input. Findings include the affected resource, the control reference and the observed configuration. The output is a configuration findings register, with each finding tied to a control ID and the evidence used to assess it. Benchmark controls are referred to by their IDs and titles, not reproduced in full.
Test exposed services within agreed limits
Once the configuration picture is clear, DeployOpen tests the services that are reachable from outside or from agreed internal network positions. Testing focuses on weakness categories such as exposed administrative interfaces, weak authentication, server-side request forgery to instance metadata endpoints, and injection through serverless event data or API inputs. Testing stays within the approved service list and the rules of engagement, and it avoids the prohibited activities. Any sign of data exposure or instability stops the affected activity and triggers a call with the client. The step closes with a log of tested components, attempted weakness categories, results and any items escalated during testing.
Validate findings and report results
DeployOpen confirms each finding by reviewing evidence and removing duplicates or false positives, then rates severity with the client using a method agreed at scoping. The report combines the CIS control results, the penetration testing findings, the affected resources, reproduction context in defensive terms, and prioritized remediation guidance. Findings that touch a service or vendor behavior are flagged for confirmation with the provider. The report is delivered in draft for a factual accuracy review, then issued in final form. The output is a final report and a remediation tracker that the client can hand to engineering teams and, where relevant, to an independent auditor.
Retest fixes and close the engagement
After the client remediates findings, DeployOpen retests the affected controls and services using the same method as the original test, then records each finding as resolved, partially resolved or still open. Retest results are added to the report as a dated addendum so that the history of the engagement remains intact. Accepted risks are documented with an owner and a review date agreed with the client. The engagement closes when the retest addendum is delivered and the client confirms the status of every finding in writing.

What needs AWS approval and what AWS prohibits

AWS lets customers test a defined set of services without asking first, but some activity needs prior approval and some is never allowed. The services that can be assessed or penetration tested without prior approval include EC2, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda, Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch Service, FSx and Transit Gateway. Any testing that includes command and control (C2) infrastructure needs prior approval from AWS. For an assessment that touches only these listed services, the practical question is whether the planned activity falls inside the policy, and that answer should be written into the statement of work before testing starts.

The policy also prohibits several activities in customer testing: DNS zone walking, hijacking or pharming through Route 53, denial of service and DDoS, port, protocol or request flooding, and S3 bucket or subdomain takeover. Scope documents should name these exclusions explicitly so that a tester does not attempt a technique that looks like normal enumeration but falls into a prohibited category. Simulated events such as red, blue or purple team exercises, DDoS simulations, simulated phishing and malware testing require a request to AWS at least 2 weeks ahead. Plan that lead time into the schedule, because a red team or phishing component added late can push the whole engagement back.

Because AWS changes its terms and service lists, confirm the current policy directly on the AWS penetration testing policy page before you sign a scope, and ask your provider to record the version they checked. Your provider should also confirm which accounts, regions and resources fall within your ownership, since the policy covers only infrastructure you control. If a component you need to test is outside the listed services or touches a prohibited technique, decide whether to exclude it, request approval, or test it through a different method.

Weakness categories an AWS assessment looks for

The table lists the weakness categories an AWS assessment typically examines, what each looks like inside an account and why it matters. Read each row as a question to ask of your own environment, then use the findings to decide where to scope testing first.

Weakness category	What it looks like in an AWS account	Why it matters
Over-broad or long-lived IAM permissions	Wildcard actions or resources in policies, roles that can attach or pass other roles, access keys that have not rotated for a long period, unused users or roles still holding permissions	An identity with more rights than its job needs turns one compromised credential into a path toward privilege escalation across the account
Public or unintended network exposure	Security groups open to 0.0.0.0/0 on administrative or data ports, internet-facing load balancers or instances that were meant to be internal, overly permissive network ACLs or Transit Gateway routes	Services reachable from the internet widen the attack surface and can expose management interfaces or databases that were never designed for public access
Storage exposure on S3 and similar services	Buckets or objects readable by everyone or by any authenticated AWS user, missing public access blocks, bucket policies that allow unexpected accounts, unencrypted or unversioned sensitive data	Exposed storage is a frequent route to data disclosure, and it often goes unnoticed because the buckets look like ordinary application storage
Disabled or incomplete logging	CloudTrail absent from some regions, trails that do not capture management or data events, logs not delivered to a protected account, no alerting on changes to logging itself	Without reliable audit trails, an assessor cannot reconstruct activity, and an incident can go undetected or be impossible to scope
Server-side request forgery to the instance metadata endpoint	Web applications or APIs that fetch user-supplied URLs, instances that allow IMDSv1 style unauthenticated metadata requests, roles attached to workloads with broad permissions	Successful forgery against 169.254.169.254 can expose temporary credentials, matching OWASP API7:2023 (Server Side Request Forgery)
Serverless entry points	Lambda functions behind API Gateway or AppSync with weak input validation, execution roles broader than the function needs, secrets stored in environment variables, unauthenticated routes	Serverless functions often hold broad permissions and sit directly on public entry points, so a single weak handler can reach data and other services

How AWS assessments fit compliance and customer reviews

Frameworks, regulators and customer security reviews increasingly expect evidence of two things for an AWS environment: a configuration review measured against a recognized baseline, and a penetration test that shows how exposed services behave under attack. An assessment produces that evidence, including findings on IAM policies, public network paths, S3 bucket settings, CloudTrail and logging coverage, and gaps against the CIS Amazon Web Services Foundations Benchmark. It does not replace the opinion of the independent auditor who evaluates your controls, and it should not be presented to a customer as an attestation. Before scoping, ask your auditor which evidence they will accept, in what format, and whether they want a configuration baseline, a test report, or both.

For financial entities in the EU, the requirements are more specific. Delegated Regulation (EU) 2024/1774 asks firms to review access rights at least every 6 months for systems that support critical or important functions (Article 21), and to run automated vulnerability scanning of those assets at least weekly (Article 10). A one-time assessment does not satisfy either requirement on its own. Practically, the assessment can establish the initial IAM baseline and scanning coverage, while your own processes and tooling carry the recurring reviews. Confirm with your compliance team and supervisor which of these obligations apply to the accounts in scope, since the answer determines whether a point-in-time report is enough or whether you need a retainer for continuous checks.

Customers and insurers often ask for a summary they can file, so plan the deliverables with that audience in mind. Agree in writing whether the report will be shared externally, whether it needs a redacted version, and how findings will be tracked to closure with dates your auditor can verify. Ask for a retest of high-severity findings so the final evidence shows remediation rather than only identification. Note the scope limits in the same document, including the accounts, regions and services covered, so that a reader does not assume the whole organization was tested. Clear scoping at this stage avoids the most common dispute in these reviews, which is a customer asking about a system that was never in the assessment.

How AWS testing differs by architecture

Virtual machines and container services are where most customer-controlled configuration lives. On EC2, ECS and Fargate, the customer owns the operating system, the application, the instance or task role, the security groups and the patching cadence, so the review spends most of its time on those settings. Amazon EC2, Amazon ECS and AWS Fargate are on AWS's list of services customers may test without prior approval, though the testing must still stay within the policy's prohibited activities.

Instance and task roles: Check whether workloads inherit broad permissions and whether instance metadata is restricted to the version that requires session tokens.
Security group exposure: Compare inbound rules against the documented service ports and flag administrative ports reachable from the internet.
Image and patch state: Review AMI or container image provenance, base image age and whether patch management is evidenced.
Container runtime settings: On ECS and Fargate, review task definitions for privileged settings, host mounts and secrets passed as plain environment variables.
Logging coverage: Confirm that host and container logs reach a central store that the workload team cannot alter.

For clusters running on EKS, the Kubernetes security assessment topic covers the control plane and workload isolation in more depth.

What you receive and whether it satisfies an auditor or customer

A cloud assessment produces several linked records, each answering a different reader. Together they show what was tested, under which rules, what was found and whether it was fixed. Check each item against what your auditor or customer actually asks for before you agree the scope.

Executive summary

A short narrative for leadership covering the agreed scope, the accounts and regions tested, the overall risk picture and the findings that need decisions first. It names the tested services and states what was excluded. Ask whether the summary can be shared with a customer without the technical appendix, and whether it lists the testing dates.

Scope and rules of engagement record

A written record of the AWS accounts, services, regions and test types agreed before work started, with the AWS testing policy conditions that applied. It shows which services were tested without prior approval and whether any simulated activity required a request to AWS. Confirm that it names the authorized tester and the approval status of each test.

Configuration review mapped to CIS

Results from the configuration review, with each check tied to the relevant recommendation in the CIS Amazon Web Services Foundations Benchmark, covering identity, logging, networking and storage. Each entry records pass, fail or not applicable, the evidence collected and the affected resources. Ask which benchmark version was used and whether the mapping is shown per control.

Penetration testing findings with severity

Each validated weakness is described with the affected resource, the weakness category, the business impact and a severity rating with the method used to set it. Findings from the configuration review and the active testing are kept distinct so readers can see what was proven. Ask how severity is defined and whether it is consistent across findings.

Evidence and reproduction notes

Screenshots, configuration exports, timestamps and request logs that support each finding, with notes that let your engineers confirm the issue without repeating an attack. Sensitive values such as keys and personal data should be redacted. Confirm how evidence is stored, who can access it and how long it is kept.

Remediation guidance and retest results

Practical fix steps for each finding, prioritized by risk and written for the cloud and platform teams who will apply them. After fixes are made, a retest confirms whether each finding is closed, partly closed or still open, with dated evidence. Ask whether retesting is included in the fixed price or billed separately.

Assessment letter for auditors or customers

A letter describing the work performed, its scope, dates and the people involved, which you can share with an auditor or a customer's security team. It describes the assessment only. It is not an audit report, attestation or certification, and only independent auditors and certification bodies can issue those. Agree the wording with your auditor before the letter is issued.

What you prepare before testing starts

Before any AWS assessment starts, the client prepares access, a complete inventory and a clear list of which activities need AWS approval. The assessor's access should match the work: read-only roles in each account for configuration review, covering IAM, VPC, S3, CloudTrail, AWS Config and the service settings that the CIS AWS Foundations Benchmark checks. Any role that allows active testing, such as a role used for exploitation of an internet-facing API, should be a separate, time-limited test role that the client creates and removes at the end of the engagement. Confirm with your own team how assessor identities are federated or issued, and whether they must sign in through your identity provider with multi-factor authentication enforced.

Next, build the account, region and service inventory that defines scope. List every AWS account in the organization, the regions in use, and the services running in each, including Lambda functions, API Gateway and AppSync endpoints, ECS and Fargate workloads, RDS and Aurora databases, and Transit Gateway attachments. Mark which accounts are out of scope, such as shared services owned by another party or accounts that hold data you cannot expose to testing. Then check each listed service against the AWS penetration testing policy, because some activities, including any testing that includes command and control, need prior approval. Simulated events such as red team exercises, DDoS simulations and simulated phishing need a request at least 2 weeks ahead under that policy. Ask your provider to confirm this list in writing before scheduling.

Name technical and escalation contacts for each account, plus someone who can stop testing at any time. Coordinate a change freeze for the test window and tell your security operations team when activity is expected, so that alerts from GuardDuty, CloudTrail or your SIEM are triaged as planned rather than as incidents. For production accounts, agree which tests run against live data, which run only in staging, and what safeguards apply, such as backups verified before testing and read-only database credentials. Also agree how the provider handles any credentials, findings or data samples it encounters. These decisions shape the cost and duration of the work, so record them in the statement of work.

What to check when choosing an AWS assessment provider

A provider's answers to the questions below show whether it can run an AWS test inside AWS's rules and your own risk tolerance. Each question addresses a point where engagements usually go wrong: unclear authority, unsafe access, weak findings, or evidence that does not reach your auditor.

Experience with AWS testing rules

Ask which services the provider has tested under AWS's penetration testing policy and how it decides when a request needs prior approval. Command and control testing needs prior approval, and simulated events such as red team exercises or DDoS simulations need a request at least 2 weeks ahead. A provider that cannot explain these lines is not ready to run the test. Ask for its process for flagging out-of-policy activity before work starts.

Written scope and named approver

Ask who writes the scope, which AWS accounts, regions and services it covers, and who on your side signs it off. A good scope lists the account IDs in the boundary, excludes shared or third-party accounts you do not own, and names the time windows for testing. Confirm that the approver has authority over the accounts in scope, since testing another team's account without consent is a breach regardless of intent.

Read-only access handling

Ask how the provider requests access, whether it uses a dedicated assessment role with read-only permissions, and how that role is time-limited and removed at the end. Ask who holds the credentials, where they are stored, and whether every API call the tester makes is logged to CloudTrail under a traceable identity. Clear answers here let your security team audit the testers' own activity.

Mapping findings to CIS recommendations

Ask whether each finding references the relevant recommendation in the CIS Amazon Web Services Foundations Benchmark, and whether it states the control result, the affected resource and the evidence used to decide it. Findings that cite a benchmark section let your team track remediation and show the same control in later assessments. Ask how the provider handles recommendations that do not apply to your architecture and how it documents that decision.

Sample report structure

Ask for a redacted sample report before you commit. Check for an executive summary, a scope and method section, a per-finding record with severity, reproduction conditions described at a defensive level, affected resources, and a remediation owner field. A report that lacks a clear list of what was not tested is less useful to an auditor than one that states its limits plainly.

Retest terms and sensitive findings

Ask whether retesting of closed findings is included in the fixed fee, how many retest rounds are covered, and how long the provider keeps working notes. Also ask how it handles sensitive findings, such as exposed credentials or data reachable across accounts. The contract should require immediate notice to a named contact, encrypted delivery of details, and deletion of any copied data at the end of the engagement.

Evidence without attestation

Ask whether the provider prepares control evidence, such as configuration exports, test records and remediation tracking, and whether it states clearly that it does not issue audit reports or attestations. Independent auditors and certification bodies draw their conclusions from that evidence. A provider that promises a certificate or a pass for a framework has overstated its role, and you should treat that claim as a warning sign.

Questions buyers ask about AWS security assessments

What does an AWS security assessment cost and what drives the price?

The price follows from the written scope, not from a standard rate, because DeployOpen does not publish a price list. The main drivers are the number of AWS accounts and regions in scope, how many services are in use (serverless, containers, data stores and identity federation each add review effort), whether the work is a configuration review, a penetration test or both, and how much testing of live systems is included. Costs are one-time for the assessment, and a retest or follow-up review is quoted separately. Ask each provider for a line-item quote that separates account and service coverage, testing activity, reporting and any retest, so you can compare like with like.

How long does an AWS security assessment take?

Duration depends on the size of the estate and how quickly the client can provide access, documentation and answers to questions. The number of accounts, the services in use, and whether the environment is mapped and tagged all affect the schedule. Testing of live services also depends on the approval steps described in the scope, and simulated events need advance notice. DeployOpen agrees the timeline in writing before work starts, so ask the provider to show which stages depend on your team, such as access provisioning, the review of findings and the retest window.

What does the client need to provide for an AWS assessment?

Expect to supply an agreed list of AWS accounts, a named technical contact, read-only access for the configuration review, and a description of the workloads, data classes and business owners. For penetration testing, you also need written confirmation of which accounts and resources the tester may target, and a clear list of anything that is out of bounds. Logging, network diagrams and existing policies speed up the review. Confirm with the provider which access model they use, how credentials are issued and revoked, and who signs off the test window.

Can our own team run an AWS security assessment in-house?

An internal team can run a configuration review against the CIS Amazon Web Services Foundations Benchmark, which is freely available in PDF for non-commercial use, and many organizations do this as a continuous practice. Independent testing is different: an internal team usually shares assumptions with the people who built the environment, and it may lack time or experience with privilege escalation paths across IAM, network exposure and serverless entry points. The in-house team needs current benchmark knowledge, access to logs and configuration data, a method for triaging findings, and a plan to stay within AWS's testing rules. An external assessment can complement this rather than replace it, and the choice depends on your risk appetite and staffing.

Does AWS need to be notified or approve a penetration test?

For many services, no prior approval is needed. AWS lets customers run security assessments or penetration tests of their own infrastructure without prior approval for a listed set of services, including EC2, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda, Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch Service, FSx and Transit Gateway. Testing that includes command and control (C2) needs prior approval. AWS also prohibits DNS zone walking, hijacking or pharming via Route 53, denial of service and DDoS, port, protocol or request flooding, and S3 bucket or subdomain takeover in customer testing. Simulated events such as red, blue or purple team exercises, DDoS simulations, simulated phishing and malware testing require a request at least 2 weeks ahead. Confirm the current terms in the AWS penetration testing policy before scoping.

Will an AWS security assessment report satisfy an auditor?

A report can serve as evidence for an auditor, but it does not replace one. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. A useful assessment report records the scope, dates, method, the benchmark controls checked, the findings with evidence and the remediation status. Before commissioning the work, ask your auditor which framework, control references and evidence format they expect, and confirm whether they accept a third-party technical test as input. Shared responsibility also matters: AWS secures the cloud infrastructure, while your configuration, data and identities are your responsibility, so the report should show what you own.

How is retesting priced after an AWS assessment?

Retesting is usually quoted separately from the original assessment because it covers a smaller, defined set of findings. The cost depends on how many findings are retested, whether fixes span multiple accounts or services, and whether the retest needs new testing activity or only a configuration check. Ask the provider to state in the quote which findings are included, how evidence of remediation is handled, and how many retest rounds are covered. Ongoing or continuous review can be arranged as a retainer, which recurs, rather than as a one-off engagement.

How DeployOpen scopes, tests, reports and retests AWS environments

DeployOpen runs AWS security assessments as fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. We test within AWS's penetration testing policy and document results so your team can act on them and retest after fixes.

How we scope

Confirm which accounts, regions and services are in the written scope before any testing begins
Check each listed service against AWS's no-approval list and flag anything needing prior approval, such as command and control
Agree on excluded actions, including DoS, flooding and S3 bucket or subdomain takeover, in writing

How we build

Review IAM policies, roles, trust relationships and long-lived keys against the CIS AWS Foundations Benchmark
Assess network exposure, storage configuration, logging coverage and the customer-owned side of the shared responsibility model
Test only resources the client owns, and confirm which services and tests must be pre-approved by AWS

How we hand over

Deliver a written report mapping findings to affected accounts, resources and CIS AWS Foundations Benchmark control IDs
Rate each finding with reproduction context, business impact and a prioritized remediation path your engineers can execute
Provide evidence packages that your auditor or customer security reviewer can read without DeployOpen present

How we support

Retest agreed findings after remediation and update the report with the status of each item
Continue support, upgrades and continuous testing through a retainer, if your environment needs ongoing coverage
Confirm with your team which evidence and retest windows your compliance framework or customer contract requires