AWS Security Baseline Checklist for Small Businesses

---

Small businesses do not need enterprise theater. They do need a cloud account that is easier to reason about and harder to misuse.

Many AWS accounts grow quickly. A developer creates access keys. A contractor receives admin permissions. A production database is launched. A few security services are enabled, but nobody is sure which alerts matter or where audit logs are stored.

That is how small teams end up with a cloud environment that works, but feels unclear.

An AWS security baseline is not about making the account perfect on day one. It is about creating a simple, explainable foundation for access control, audit visibility, and account guardrails.

This checklist is written for small businesses that need practical AWS security improvements without building a heavy enterprise security program.

Start with account ownership

Before adding more tools, confirm who owns the AWS account and who can make important changes.

Review:

• Who has access to the AWS account root user.
• Whether root access is protected with MFA.
• Who receives AWS billing, security, and abuse notifications.
• Who can create IAM users, roles, policies, and access keys.
• Who can change CloudTrail, GuardDuty, Security Hub, or logging settings.
• Who is responsible for reviewing security gaps.

The AWS account root user should not be used for daily work. Keep it protected, documented, and reserved for tasks that truly require it.

For small teams, unclear ownership is one of the biggest risks. If nobody owns the account baseline, nobody maintains it.

Access and identity

Identity is the first place to reduce risk.

Start by reviewing broad access:

• Who has administrator permissions?
• Are there old IAM users that nobody owns?
• Are there access keys that have not been rotated or used recently?
• Are contractors, freelancers, or previous employees still present?
• Are people sharing one login instead of using named access?
• Are production roles separated from development roles?

Prefer role-based access over informal shared access. Each person should have access that matches their actual responsibility.

A simple access baseline should include:

• MFA for privileged access.
• No shared daily admin user.
• Named users or federated identities for people.
• IAM roles for workloads and automation.
• No long-lived access keys unless there is a clear reason.
• Regular review of admin-level permissions.
• Clear separation between human access and application access.

Small businesses often start with one admin user for everything. That may feel fast at the beginning, but it becomes dangerous as soon as the account has production workloads, client data, or multiple people making changes.

Remove stale access paths

Stale access is access that still exists even though the reason for it is gone.

Examples include:

• Old IAM users created for a one-time migration.
• Access keys used by scripts that no longer run.
• Contractor accounts after the project ended.
• Admin roles created for testing.
• Unused GitHub, CI/CD, or deployment credentials.
• Old EC2 key pairs that nobody tracks.
• IAM policies attached directly without clear purpose.

For each stale access path, decide whether to remove it, reduce it, or document why it must stay.

The goal is not only to reduce permissions. The goal is to make access understandable.

Logging and audit visibility

Security is much harder when the team cannot answer basic questions:

• Who changed this setting?
• When was this resource created?
• Which identity made this API call?
• Was logging disabled?
• Did someone change a security group?
• Did an access key get used from an unusual place?

At minimum, confirm that CloudTrail coverage exists and that important events are retained.

Review:

• CloudTrail is enabled for the account.
• Management events are being recorded.
• Logs are delivered to a protected S3 bucket.
• Log file validation is enabled where appropriate.
• Log retention is long enough for investigation.
• Only trusted admins can change or delete audit logs.
• The team knows where to search during a change or incident.

For small teams, audit visibility does not need to be complex. It needs to be reliable enough to answer what changed and who changed it.

Enable practical threat detection

After identity and logging are under control, enable practical detection services.

A small business baseline may include:

• GuardDuty for threat detection.
• Security Hub for security findings and best-practice checks.
• AWS Config where configuration history and compliance tracking are needed.
• CloudWatch alarms for critical security-related events.
• Billing alarms or AWS Budgets for unexpected cost spikes.

The goal is not to enable every possible security service. The goal is to create a useful signal that the team can actually review.

If findings are enabled but nobody checks them, the baseline is incomplete.

Guardrails

Guardrails reduce common mistakes.

For a small business, useful guardrails may include:

• Preventing public S3 bucket exposure where it is not required.
• Restricting who can create access keys.
• Requiring MFA for privileged actions where practical.
• Limiting admin access to trusted roles.
• Protecting logging resources from deletion.
• Separating production and non-production environments.
• Restricting regions if the business only uses specific AWS regions.
• Reviewing security groups that expose SSH, RDP, databases, or admin panels.

If AWS Organizations is used, Service Control Policies can help enforce boundaries. Start carefully. Test policies before applying them broadly, especially in production environments.

Guardrails should reduce risk without blocking the team from operating the business.

Network and exposure review

Small businesses often have unnecessary public exposure in AWS.

Review:

• Security groups allowing SSH from 0.0.0.0/0.
• Security groups allowing RDP from 0.0.0.0/0.
• Public databases.
• Public Elasticsearch/OpenSearch endpoints.
• Public admin panels.
• Load balancers exposing internal services.
• Unused Elastic IPs.
• Old test servers still running.
• S3 buckets with public access exceptions.

Every public entry point should have a clear reason.

For admin access, prefer restricted IPs, VPN, SSM Session Manager, or another controlled access method instead of leaving management ports open to the internet.

Backup and recovery baseline

Security also includes recovery.

A small business should know whether it can recover from deletion, compromise, or accidental change.

Review:

• Which workloads need backups.
• Whether RDS automated backups are enabled.
• Whether snapshots are retained long enough.
• Whether critical S3 data has versioning or backup coverage.
• Whether EC2 workloads need AMI or volume snapshots.
• Who can delete backups.
• Whether restore has been tested.

Backups that are never tested are only assumptions.

A practical baseline should include at least one documented restore check for important systems.

Documentation

The security baseline should be written down in a simple format.

Document:

• AWS account name and purpose.
• Account owner.
• Production workloads.
• Admin access list.
• Logging status.
• Security services enabled.
• Important guardrails.
• Backup coverage.
• Known gaps.
• Next actions.

This document should not be a long policy file nobody reads. It should be short enough to review and update.

Treat the baseline as a working control document, not a one-time exercise.

Small business AWS security checklist

Use this checklist as a starting point:

• Root user is protected and not used for daily work.
• MFA is enabled for privileged access.
• Admin access is reviewed and documented.
• Old IAM users are removed or disabled.
• Unused access keys are removed.
• Workloads use IAM roles instead of hardcoded credentials.
• CloudTrail is enabled and retained.
• Audit logs are protected from accidental deletion.
• GuardDuty is enabled where needed.
• Security Hub is enabled where findings will be reviewed.
• Public S3 access is reviewed.
• Security groups are checked for open SSH, RDP, database, and admin ports.
• Production and non-production access are separated.
• Backups exist for critical workloads.
• Restore process is documented or tested.
• Security gaps are listed with owners and priority.
• The baseline is reviewed regularly.

What to fix first

If the AWS account feels messy, start with the highest-impact items:

1. Protect the root user.
2. Review admin access.
3. Remove stale IAM users and access keys.
4. Confirm CloudTrail logging.
5. Review public exposure.
6. Enable practical detection.
7. Document gaps and owners.

This order gives small teams a cleaner foundation before moving into more advanced security controls.

Final thoughts

AWS security for a small business does not need to start with a complicated landing zone project. It should start with clarity.

Know who has access. Know what is logged. Know what is exposed. Know where alerts go. Know what still needs work.

A simple, maintained baseline is better than a complex security setup nobody understands.

Next step

If the account baseline is still messy or unclear, review the AWS Secure Landing Zone service.