AWS Security Due Diligence: Accounts and Identity

When it comes to acquiring a company that runs its workloads in AWS, proper security due diligence isn’t just recommended; it’s essential for protecting your investment and avoiding costly surprises. If you were not to have a comprehensive cloud security assessment performed before acquiring a company, you are essentially buying blind, exposing yourself to post-acquisition headaches and liabilities that could have been identified and addressed during negotiations.

The reality is: undisclosed security vulnerabilities can lead to millions in remediation costs, regulatory compliance violations, integration delays, and inherited data breach liabilities that far exceed the cost of thorough upfront assessment. In my experience conducting AWS security assessments for enterprise M&A transactions while at Amazon Web Services (AWS), I’ve consistently seen that the deals with the smoothest post-acquisition integrations are those where security due diligence was prioritized from day one, giving acquirers the visibility they need to make informed decisions and negotiate appropriate deal terms.

This will be a three part series. The following will be the posts in this series:

• Part 1 - AWS Security Due Diligence for M&A: Accounts and Identity
• Part 2 - AWS Security Due Diligence for M&A: Infrastructure and Data Protection
• Part 3 - AWS Security Due Diligence for M&A: AppSec and Incident Response

In this post, I will cover the foundational security controls that M&A teams must assess before closing any deal that involves organizations that run key workloads on AWS, including account management, identity and access controls, and threat detection capabilities. This guide provides practical red flags, assessment questions, and cost implications to help acquirers identify deal-breaking security issues that could lead to millions in post-acquisition remediation costs or inherited breach liabilities.

Now let’s jump in.

Pre-Due Diligence: What Acquirers Need to Know

Next, let’s focus on the things you should find out before you kick off your security due diligence assessment. These are things you should discover upfront since some of them could be deal killers.

Security & Compliance Red flags

Data breaches

One of the first things you will want to discover is whether the company has experienced any data breaches in their AWS environment. Finding this out is key because it provides insight into their security posture. However, one of the most important aspects is that you’ve identified a critical risk that could open you up to potential liability after acquiring the company. This could be potentially a deal killer before the security due diligence even gets started.

This is concerning because you don’t know what the incident response was to the breach. I would ask myself: what if the bad actor during the data breach built in a backdoor, and after you acquire the company, they gain access to your data? I would find out if there is any documentation related to the issue, including forensic reports, and remediation steps taken.

Lack of Basic Security Policies

When a company lacks basic security policies, it signals that security is managed ad-hoc, presenting significant concerns from an acquisition perspective. If the organization has no security policies that personnel must abide by, there is a high likelihood that breaches have occurred in their environments. These breaches could be from outside attackers or potential inside threats from current or former employees. Breaches are likely in situations like this because there is usually no process for creating users, granting access to AWS accounts, or elevating permissions.

In my experience running security assessments, users often have more permissions than they need, and there are frequently orphaned IAM users that have not been used for years but remain active. This lack of governance creates significant post-acquisition integration challenges and potential compliance violations.

In scenarios like this, you should find out what the current manual process is for creating users, how user permissions are assigned, and how permissions are updated for IAM users, roles, and policies. This will give you a better understanding of where some of the security gaps are.

Regulatory Non-Compliance Violations

If the company that is being acquired operates in a regulated space such as finance, healthcare, or government, they likely have to abide by some type of regulatory framework. For example, if a company handles financial data, they would have to be compliant with PCI-DSS, or if they deal with healthcare data, they would need to be HIPAA compliant.

If the company has been non-compliant in the past, you will probably want to get an understanding of the infraction to determine how that could potentially affect the deal. If a company has been non-compliant in the past, that is not only a security issue but a governance problem. Regulatory violations can result in ongoing fines, contract losses, and expensive remediation requirements that significantly impact deal value.

For compliance issues that are uncovered, you could request compliance audit reports from the past 3 to 5 years, correspondence related to regulatory violation notices, warning letters, or settlement agreements from regulators, and third-party compliance assessments conducted by external auditors or consulting company.

AWS Account Management and Identity Access Control

How a company organizes and controls its AWS accounts tells you everything about its security discipline. During M&A cybersecurity due diligence, account management and identity controls reveal whether you’re acquiring a well-governed organization or inheriting a security nightmare.

Account Structure and Root Account Security

Smart companies separate development, testing, and production workloads across different AWS accounts while securing root access properly.

Red flags to watch for:

• Everything running in a single AWS account with production and development mixed
• Root accounts used for daily work
• Root accounts have no multi-factor authentication (MFA)
• No clear separation between sensitive and non-sensitive data
• Root passwords stored insecurely or access keys attached to root accounts

What good management looks like:

• Separate accounts for each environment (dev, test, prod) and business units
• Root accounts protected with MFA (preferably using hardware keys) and only used for emergency access
• Clear naming conventions that make account purposes obvious
• Root access properly documented and audited

Identity Management and Authentication

Organizations should implement centralized identity providers when creating users across all of their AWS accounts. When authentication is not centralize this tends to lend to poor identity management and creates the high risk for post-acquisition security incidents and compliance violations.

Essential Authentication Requirements

During your assessment, verify these authentication capabilities are properly implemented:

• Use of AWS Identity Center (SSO) or a reputable third-party identity provider (Okta, Ping, etc) for single sign-on
• MFA enabled on all user accounts, especially on accounts with elevated rights
• Hardware tokens or mobile apps rather than SMS-based MFA
• Automated user provisioning and removal processes

Deal-impacting red flags:

• Manual user creation without approval workflows
• Former employees with active AWS access (orphaned accounts)
• Shared accounts between multiple people
• Service accounts using personal email addresses
• No regular reviews of active user accounts

If a company manages users manually or allow password-only access this will create immediate breach risks and significant cleanup costs.

Financial impact considerations:

• Average remediation cost for identity-related breaches: $1.2 million
• Former employee access creates potential for data theft and sabotage
• Manual user management requires 3-6 months to standardize post-acquisition
• Shared accounts make forensic analysis impossible during incidents

Questions to ask during assessment:

• How many former employees still have active AWS access?
• What is your process for removing user access when someone leaves?
• Can you provide a complete list of all administrative users that have access to your AWS accounts?
• How do you verify user identities before granting access?

Access Control and Privileged Access

Users and applications should receive only minimum permissions needed while maintaining proper oversight of administrative access. Over-privileged users represent the greatest insider threat risk during M&A transitions.

Least Privilege Implementation

Critical access controls to verify:

• Users receiving only permissions needed for their specific job roles
• Applications using IAM roles instead of embedded access keys
• Temporary credentials with automatic rotation process
• Regular reviews of who has access to what across all AWS accounts

Privileged access management:

• Separate administrative accounts from regular user accounts
• Process for creating time-limited administrative access that expires automatically
• Break-glass emergency access procedures with proper approval workflows
• Complete logging and monitoring of all administrative activities

Deal-breaking warning signs:

• Users with administrative access who don’t need it
• Policies granting broad “everything” permissions
• Hard-coded credentials in applications or configuration files
• Regular users with permanent administrative access

M&A risk assessment:

Companies with poor access controls may have employees who can access systems they shouldn’t, creating insider threat risks during the transition period. This is particularly dangerous when layoffs or role changes occur post-acquisition.

Validation during due diligence:

• Request a complete IAM policy review and user permission audit
• Verify separation of duties for sensitive operations
• Review access revocation procedures and timelines
• Assess complexity of integrating with your existing access controls

Cross-Account Access and Monitoring

When a company is managing multiple AWS accounts, they will need to ensure secure cross-account access and oversight. If cross-account access is not carefully managed, it creates hidden attack vectors.

Secure Account Connectivity

Best practices to verify:

• Cross-account roles with temporary credentials instead of long lived accounts
• Time-limited access tokens rather than permanent keys
• Clear documentation of which accounts can access what
• Service-to-service authentication using IAM roles

Essential monitoring capabilities:

• CloudTrail logging enabled across all AWS accounts with centralized logging to a dedicated AWS logging account
• Alerts for suspicious login patterns or unusual activity
• Regular access reviews tracking resource access and privilege escalation attempts
• Integration with security incident response procedures
• Automated notifications to security violations

Assessment red flags that impact deal value:

• No centralized monitoring making incident response impossible
• Gaps in logging that prevent forensic analysis
• Cross-account access granted without proper documentation

Due diligence implications:

Without proper cross-account monitoring, you cannot verify the security posture across all parts of the environment. This makes it impossible to assess the true scope of security risks you’re inheriting.

Automation and Compliance

Most mature organizations implement automated security controls and maintain compliance-aware practices. When a company is lacking automation the acquiring company has a high likelihood of facing significant post-acquisition remediation costs.

Key Automation Assessment

Automation maturity indicators:

• Policies preventing users from disabling security services
• Automatic encryption enforcement for sensitive data
• Geographic restrictions on resource creation
• Service Control Policies enforcing organizational standards
• Automated detection of unused or excessive permissions

Compliance and recovery planning requirements:

• Audit trails showing who accessed what data and when
• Documented procedures for account compromise or deletion scenarios
• Tested recovery procedures that work during emergencies
• Cross-region backup strategies for business continuity
• Quarterly reviews of all user permissions and roles

Critical compliance verification:

• Segregation of duties controls preventing conflicts of interest
• Regular compliance reporting and gap analysis
• Manager certification that subordinates need their current access levels

Post-acquisition integration considerations:

• Companies with mature automation integrate more smoothly with your existing systems
• Manual security procedures require 6-12 months to automate post-acquisition
• Budget $200K to $1M for security automation upgrades when calculating deal value
• Compliance gaps can delay integration and create regulatory exposure

Red flags indicating poor security operations:

• All security procedures performed manually without automation
• No documented compliance mapping or gap analysis
• Recovery procedures never tested or outdated
• Security controls that can be easily disabled by users

When companies rely on manual procedures, lack tested recovery plans, or don’t have compliance-aware practices, they face extended downtime risks. These gaps can lead to regulatory fines that significantly impact deal valuation. Organizations with comprehensive automation and compliance integration demonstrate security maturity and reduce post-acquisition integration risks.

Detection Capabilities

During M&A cybersecurity due diligence, detection capabilities reveal whether you’re acquiring a company that can quickly identify and respond to security threats or one that operates blind to attacks. Poor detection systems create hidden liabilities that can surface as costly incidents post-acquisition.

Security Monitoring and Threat Detection

Essential Detection Services Assessment

Companies should deploy comprehensive monitoring tools to catch suspicious activity across their AWS environment. During your assessment, verify these baseline set of services are properly enabled and implemented:

• CloudTrail for centralized logging of all API activity across accounts
• Amazon GuardDuty for malware detection and unusual AWS account activity
• AWS Security Hub for centralized security findings management
• AWS CloudWatch for application and infrastructure monitoring
• VPC Flow Logs for network traffic analysis
• DNS query logging for suspicious domain requests

Deal-impacting red flags:

• Monitoring tools deployed but never configured or updated
• Security alerts ignored or sent to unmonitored email addresses
• Detection coverage missing in critical AWS regions or AWS accounts
• No integration between detection tools, creating blind spots
• No Detection services deployed at all

If a company has inadequate detection controls in place, there will be security gaps and they may have active threats they’re unaware of. This creates immediate post-acquisition security risks and potential breach liabilities you’ll inherit.

Financial impact considerations:

• Average cost of undetected breaches: $4.76 million according to IBM’s Cost of Data Breach Report
• Integration delays when combining insecure environments with your systems
• Emergency security upgrades required before safe integration can proceed

Log Management and Analysis

Comprehensive Logging

Effective security requires collecting and analyzing logs from all AWS Accounts. These logs also provide critical visibility into the company’s security posture during your assessment. The following are some of the types of logs that should be collected:

Logs to collect:

• CloudTrail for all API calls and administrative actions
• Application logs from EC2 instances and containers
• Database activity logs from RDS and other data stores
• Load balancer access logs for web traffic analysis
• Authentication logs from identity providers

Assessment red flags that impact deal value:

• Logs stored only locally on individual systems (no centralized analysis)
• Log retention periods shorter than compliance requirements
• Missing logs from critical systems during assessment period
• No automated analysis tools to identify security incidents
• Gaps in logging that prevent forensic analysis of past incidents

Due diligence implications:

Companies without proper logging cannot provide evidence of their security posture during due diligence assessments. When logs are not collected, it’s impossible to verify claims about past security incidents or demonstrate compliance with regulatory requirements.

Questions to ask during assessment:

• Can you provide 12 months of CloudTrail logs for analysis?
• What security incidents have been detected in the past year?
• How quickly can you identify the scope of a potential breach?
• Are there any gaps in your logging coverage?

Incident Response Integration

Detection Response Capabilities

During M&A due diligence, evaluate whether detection systems actually trigger appropriate response actions when threats are identified. There’s nothing worse than thinking you have an alarm system and then realize it doesn’t work when you need it.

Critical response capabilities to verify:

• Automated alerts sent to monitored security teams (not generic email)
• Documented response playbooks for common attack scenarios
• Clear escalation procedures with defined response timeframes
• Regular testing of detection and response procedures

Deal-breaking warning signs:

• Security alerts routinely ignored or delayed
• No documented incident response procedures
• Security team overwhelmed by false positive alerts
• Response tools disconnected from detection systems
• Long delays between threat detection and containment actions

M&A risk assessment:

Companies with poor incident response may have ongoing security incidents they haven’t properly contained, or they may be completely unaware that incidents have occurred. This creates liability risks and potential business disruption during integration.

Validation during due diligence:

• Request documentation of recent security incidents and response times
• Verify security team staffing and availability (24/7 coverage vs. business hours only)
• Review incident response test results and lessons learned
• Assess integration complexity with your existing security operations

Performance and Operational Maturity

Detection System Effectiveness

You can evaluate a company’s operational security maturity by finding out how they maintain and optimize the detection systems they have in place.

Operational maturity indicators:

• Detection rules customized for the organization’s specific environment
• Regular tuning to reduce false positives without missing real threats
• Threat intelligence integration to improve detection accuracy
• Active threat hunting activities complementing automated detection
• Performance monitoring ensuring detection systems don’t impact operations

Red flags indicating poor security operations:

• Detection tools deployed with default configurations never updated
• High false positive rates causing alert fatigue
• No metrics tracking detection system performance
• Security team reactive rather than proactive in threat hunting
• Detection capabilities never tested against real attack scenarios

Post-acquisition integration considerations:

• Companies with mature detection operations integrate more easily with your security systems
• Poor detection maturity requires significant investment to bring up to enterprise standards
• Factor remediation costs (typically $500K to $2M) into deal valuation for immature security operations
• Timeline impact: upgrading detection capabilities can delay integration by 3-6 months

Assessment recommendation:

Request a demonstration of their detection capabilities during due diligence. Companies with mature security operations can quickly show you their dashboards, recent alerts, and response procedures. Those operating with poor detection will have little to demonstrate.

From the Field

During my time at AWS as a security specialist, I’ve seen that many companies have some type of security gap in their AWS environment. While some organizations excel at security and compliance, others operate with significant vulnerabilities that could derail an acquisition or saddle you with costly remediation requirements. That’s why conducting your own cloud security assessment or hiring an independent company to perform the cloud security assessment should be non-negotiable in your M&A due diligence process if the company being acquired runs any of their workloads in the cloud. The insights gained from a thorough security evaluation will not only protect your investment but also give you the leverage needed to negotiate appropriate deal terms, plan realistic integration timelines, and avoid the unpleasant surprises that can turn a promising acquisition into a costly mistake.

At Avinteli, we specialize in comprehensive AWS security assessments that can help you through your M&A due diligence, helping acquirers identify critical risks and make informed decisions before closing deals. Our experience conducting enterprise-scale AWS security assessments ensures you get the detailed analysis needed to protect your investment and negotiate from a position of strength. In Part 2 of this series, we’ll dive deeper into infrastructure protection and data security controls that are equally critical to assess before closing any deal.

Other Blogs

• Part 1 - AWS Security Due Diligence for M&A: Accounts and Identity
• Part 2 - AWS Security Due Diligence for M&A: Infrastructure and Data Protection
• Part 3 - AWS Security Due Diligence for M&A: AppSec and Incident Response