AWS Foundational Technical Review: FTR Checklist and Prep Guide for SaaS Teams

Short answer: The AWS Foundational Technical Review (FTR) is AWS's check of a partner solution against security, reliability and operational best practices from the AWS Well-Architected Framework. SaaS companies complete it to earn software validation and partner program access. You close gaps against the FTR requirements, then upload a recent SOC 2 Type II report or an AWS Well-Architected Framework Review (WAFR) report in AWS Partner Central. AWS checks it automatically and returns approval or feedback within minutes.

Related guides:

• 21 AWS cloud security strategies to transform your business
• AWS compliance integration: automate SOC 2 and ISO 27001 evidence collection
• SOC 2 compliance checklist: every requirement, control and evidence item

Key takeaways

• The AWS FTR is a baseline technical review, not a full audit. It focuses on a defined set of controls around account security, identity, logging, encryption, resilience and operations.
• Passing the FTR is a requirement for AWS Partner software validation and the AWS Qualified Software designation, and it is a prerequisite for co-sell programs such as ISV Accelerate.
• You validate by uploading a SOC 2 Type II report or a WAFR report. The review is automated, and an approval is valid for two years.
• The checklist differs by solution type. Partner-hosted SaaS and customer-deployed software are reviewed against different requirement sets.
• Most failures come from a small number of basics: root account usage, long-lived access keys, missing CloudTrail coverage and undocumented recovery objectives.
• Much of the evidence you gather for the FTR maps directly to SOC 2 and ISO 27001 controls, so prepare it once and reuse it.

---

What is the AWS Foundational Technical Review?

The AWS Foundational Technical Review is a structured assessment AWS uses to confirm that a partner's software solution follows a baseline of security, reliability and operational best practices.

The requirements are drawn from the AWS Well-Architected Framework, but the FTR is much narrower than a full Well-Architected review. It asks whether a specific list of foundational controls is in place for the AWS accounts and workloads behind your offering.

AWS publishes separate FTR checklists depending on how your solution is delivered:

Solution type	What it means	Where the review focuses
Partner-hosted (SaaS)	You run the software in AWS accounts you control and customers consume it as a service	Your own AWS accounts: root protection, IAM, logging, encryption, backups, tenant data handling
Customer-deployed	Customers install and run your software in their own AWS accounts (for example via templates, AMIs or containers)	The deployment artifacts and guidance: least-privilege permissions, secure defaults, documentation of what the software needs

If you offer both a hosted and a self-deployed version, expect to address both requirement sets. AWS updates these checklists over time, so download the current version from AWS Partner Central before you start.

Why does the FTR matter for SaaS and HealthTech companies?

The FTR matters because it is the technical gate between "we run on AWS" and "AWS actively helps us sell."

Passing the review is required for AWS Partner software validation, which leads to the AWS Qualified Software designation. That validation is in turn a prerequisite for programs such as ISV Accelerate, AWS's co-sell program for qualifying software partners. For a small company, co-selling and a stronger AWS Marketplace presence can shorten the path to enterprise buyers.

For HealthTech companies, hospital systems and payers ask pointed questions about how patient data is stored, encrypted, backed up and monitored. A passed FTR does not replace HIPAA obligations or a SOC 2 report, but it gives you an AWS-reviewed baseline to point to in security questionnaires.

An FTR approval is not permanent. It is valid for two years, so treat the FTR as an ongoing control set, not a one-time project.

How does the FTR process work, step by step?

AWS has streamlined the FTR: instead of a manual review, you upload an existing assurance report and an automated check validates it.

1. Scope your solution. Identify every AWS account that hosts production workloads, customer data, logs or backups for the offering, and decide which solution type applies.
2. Meet the Partner Central prerequisites. The solution must be linked to a single AWS Marketplace software product that runs on AWS, with Partner Revenue Measurement enabled.
3. Close gaps against the FTR requirements. Record whether you meet each requirement, how, and what evidence proves it. A requirement you "mostly" meet is a gap.
4. Get a validation report. As of September 2026, AWS accepts a SOC 2 Type II report issued within the last year, with an unqualified opinion, the Security and Availability criteria, and your AWS-hosted solution in scope. Or run a WAFR in the AWS Well-Architected Tool that is less than a year old and has no high-risk issues in the Security, Reliability and Operational Excellence pillars.
5. Request validation in AWS Partner Central. Upload the report on the solution's Validation tab. The automated check returns approval or specific feedback within minutes, and you can resubmit as often as needed.
6. Maintain. Keep controls in place and your report current so you are ready to re-validate before the two-year approval expires.

Most of the effort sits in steps 3 and 4. Teams that have been through a SOC 2 audit tend to move faster because the evidence habits already exist.

What do AWS FTR requirements actually cover?

AWS FTR requirements cluster into a handful of foundational areas that map closely to cloud security fundamentals.

Wording varies between checklist versions, but a partner-hosted SaaS offering should expect to address:

• Root account protection. MFA on the root user, no root access keys, and accurate account contact details.
• No root for daily tasks. Daily work uses IAM roles or federated identities, never root.
• IAM least privilege. Permissions scoped to need, with workloads using roles and temporary credentials instead of long-lived access keys.
• MFA for human access. Console users, especially administrators, sign in with multi-factor authentication.
• Logging with CloudTrail. CloudTrail enabled across in-scope accounts and Regions, with logs protected from tampering.
• Encryption at rest and in transit. Databases, storage and volumes encrypted at rest, and TLS for data in transit.
• Backup and recovery. Defined recovery point objectives (RPO) and recovery time objectives (RTO), backups that meet them, and tested restores.
• Network security. Restricted inbound access, no management interfaces open to the internet, and sensible segmentation.
• Incident response contacts. Security contacts registered on the account and a documented way to act on notifications.
• Customer data handling. Clear answers on where customer data lives, how tenants are isolated, and what happens when a customer leaves.

If you want a broader view of these controls in a multi-framework context, our guide to cloud security controls covers the wider landscape.

Where do teams most often fail the FTR?

Most FTR findings come from basic account hygiene that drifted over time, not from sophisticated architectural gaps.

Common patterns for small SaaS teams:

• Old root access keys. A key created years ago for a quick script still exists.
• Shared admin users. One administrator IAM user shared by several engineers, often without MFA.
• Long-lived keys in CI/CD. Pipelines authenticate with static access keys instead of roles.
• Partial CloudTrail coverage. Logging misses some Regions or accounts, or logs sit where admins can delete them.
• "We have backups" without numbers. Snapshots exist, but no RPO, RTO or restore test is documented.
• Forgotten accounts. A legacy account holding copies of production data was left out of scope.
• Missing account contacts. Alternate contacts are blank or point to former employees.
• Thin documentation. Controls exist in practice, but nothing is written down to show your SOC 2 auditor or WAFR reviewer.

Most fixes are quick once found, which is why a thorough internal check before your audit or WAFR pays off.

FTR readiness checklist: what to verify before you submit

Use this table to check a partner-hosted offering before your SOC 2 audit or WAFR, since gaps here tend to surface as audit exceptions or high-risk issues. Confirm the details against the current official FTR requirements for your solution type.

Area	What to verify	Evidence to have ready
Root account	MFA enabled, no root access keys, root not used for routine work	IAM credential report, MFA status, account settings screenshot
Account contacts	Security, operations and billing alternate contacts are current	Account contact settings
Identity and MFA	Human access through SSO or IAM with MFA, no shared users	Identity provider configuration, list of users and MFA status
Least privilege	Roles scoped per function, admin access limited and reviewed	IAM policies, access review record
Credentials	Workloads and pipelines use roles and temporary credentials	Pipeline configuration, list of active access keys and their age
Logging	CloudTrail enabled across in-scope accounts and Regions, logs protected	Trail configuration, log bucket policy
Encryption at rest	Databases, storage and volumes encrypted	Resource encryption settings, key management configuration
Encryption in transit	TLS enforced on public endpoints and internal data paths	Load balancer and endpoint configuration
Backup and recovery	RPO and RTO defined, backups scheduled, restore tested	Backup policy, restore test record
Network security	No unrestricted inbound access to management ports, segmentation in place	Security group rules, network diagram
Incident response	Documented process for receiving and handling security events	Incident response plan, on-call or contact list
Customer data	Data locations, tenant isolation and offboarding documented	Data flow diagram, data handling procedure

How does FTR evidence overlap with SOC 2 and ISO 27001?

A large share of FTR evidence is the same evidence auditors ask for in SOC 2 and ISO 27001, so you can collect it once and map it to all three.

SOC 2 is an independent attestation against the AICPA Trust Services Criteria, and ISO 27001 certifies an information security management system. The FTR is narrower, but the underlying controls overlap heavily:

FTR area	SOC 2 (Trust Services Criteria)	ISO 27001 (Annex A themes)
Root protection, MFA, least privilege	Logical access controls in the Common Criteria	Access control, identity management, privileged access
CloudTrail logging	System monitoring and anomaly detection	Logging and monitoring
Encryption at rest and in transit	Protection of data and transmission security	Use of cryptography
Backup, RPO and RTO	Availability criteria and recovery planning	Information backup, ICT readiness for business continuity
Network security	Boundary protection within logical access	Network security controls
Incident response contacts	Incident detection and response	Information security incident management
Customer data handling	Confidentiality and data disposal	Information classification, deletion, data leakage prevention

If you already hold SOC 2 or ISO 27001, FTR prep is often a matter of pulling AWS evidence you already have. If the FTR comes first, framework-neutral evidence gives you a head start on those audits. Our comparison of ISO 27001 vs SOC 2 can help you decide which audit to tackle next.

How SecureSlate helps

SecureSlate gives you a single control library mapped across frameworks, so the IAM, logging, encryption and backup controls behind your FTR are the same controls you track for SOC 2, ISO 27001 and HIPAA. Automated evidence collection from your AWS accounts and SaaS stack helps you spot drift, such as a new access key or a disabled trail, before it turns into a finding.

Policy templates cover the incident response, backup and access control procedures reviewers expect to see written down, while the risk register and vendor risk management keep the rest of your program organized. Because a SOC 2 Type II report is one of the two ways to pass the FTR, SecureSlate helps you prepare for the independent audit that produces that report, and a trust center lets you share it with customers.

Start your free SecureSlate trial

FAQ

Is the AWS Foundational Technical Review the same as a Well-Architected review?

No. The FTR draws its requirements from the AWS Well-Architected Framework, but it is a narrower review focused on a defined set of foundational controls. A full Well-Architected review goes deeper across every pillar. A recent WAFR report with no high-risk issues in the Security, Reliability and Operational Excellence pillars is one of the two reports AWS accepts for FTR validation.

Who performs the FTR?

The review is automated. You upload a SOC 2 Type II report or a WAFR report in AWS Partner Central, and AWS checks it against its validation rules within minutes. A WAFR can be self-service or run with help from AWS or a Well-Architected partner.

Do I need SOC 2 or ISO 27001 before the FTR?

You need either a SOC 2 Type II report or a WAFR report to validate. A SOC 2 Type II issued within the last year, covering Security and Availability with your AWS-hosted solution in scope, is accepted directly. ISO 27001 is not one of the accepted reports.

How long does an FTR approval last?

An FTR approval is valid for two years. AWS Partner Central shows the expiration date on the solution's Validation tab, so plan a current SOC 2 Type II or WAFR report before it lapses.

Does the FTR apply to HealthTech companies handling PHI?

The FTR applies based on your AWS partner goals, not your industry. HealthTech companies still need to meet their own HIPAA obligations separately, but the FTR's controls on encryption, logging and backups support those efforts.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.