AWS Security Audit for Non-Profits on a Budget: The Plan That Closes the Funder Questionnaire Without Blowing the Mission Spend
Alexander Sverdlov
Security Analyst
Key Takeaways
- Most non-profit AWS environments we audit have three recurring categories of finding driven by the same root cause: a multi-year credit grant that funded build but never funded operate. Closing them is largely a configuration exercise, not a tooling purchase
- The single biggest cost lever is scope discipline. A 1-account environment costs roughly USD 3,200 to audit honestly; the same workload spread across 14 unmanaged sub-accounts costs USD 11,500 to audit and twice that to remediate
- Three controls (root account hardened with hardware MFA, CloudTrail centralized with immutable storage, public S3 detection wired to an actually-monitored alert) close roughly 65 percent of real-world findings on a non-profit AWS tenant
- AWS itself offers three free or near-free services that account for a third of what most paid auditors run on you: AWS Trusted Advisor (free at Business support tier), AWS Security Hub free posture findings, and the AWS Well-Architected Tool. Knowing what each one actually covers is half the audit
- A defensible audit for a small non-profit AWS environment (1-3 accounts, under 30 staff) sits in the USD 3,200 to USD 7,500 band and ships in 7 to 12 business days. The same audit done by a self-described "cybersecurity firm" that quotes USD 22,000 is usually quoting two-thirds of the bill in scope items the non-profit does not have
- Four delivery paths exist: pro-bono partner audit, foundation-funded audit with a named line item, fixed-fee specialist boutique, or in-kind audit-clinic-style audit through a state non-profit technology assistance program. Picking the right path is worth 60 to 80 percent of the budget
An executive director at a 38-person social-services non-profit emailed me on a Friday in February. The subject line read "Funder request, due in 18 business days." The body forwarded one paragraph from a USD 1.4M operating grant renewal letter. The paragraph asked for a current AWS security review covering the case management platform that holds client intake records, IRB-protected research data, and the donor management system. The audit had to be performed by a party independent of the contracted AWS partner who built the platform. The annual budget line item for cybersecurity, including the audit, the remediation, and any tooling, was USD 9,600.
She had already received three quotes. A regional managed-service provider had quoted USD 28,500 for a "comprehensive cloud security assessment." A self-described AWS expert had quoted USD 18,000 for a "Well-Architected review." The AWS partner who built the platform had offered to do the audit for free if she signed a three-year managed-services renewal worth USD 64,000 a year.
None of those answers worked. The first two ate her entire annual technology budget and most of next year's. The third had the same conflict of interest as a vendor auditing their own work, and the funder had specifically excluded it.
We scoped a 9-business-day audit at USD 4,200 fixed price, ran it against three AWS accounts and one Route 53 hosted zone, delivered a findings register with 17 items ranked Critical to Low, shipped a 30-day remediation plan, and signed an independent attestation letter the funder accepted on first read. The grant renewed on Day 16. Below is what was inside the audit, what the findings turned out to be, and the four ways non-profits like hers actually fund work like this without raiding the mission budget.
Section 1
Why a Non-Profit AWS Audit Is a Different Problem From an Enterprise One
Most published AWS audit guidance assumes a budget that a non-profit does not have, a team that a non-profit does not staff, and a threat model that does not match where non-profit data actually sits. Before we walk through controls, agree on the framing.
A non-profit AWS environment, in the vast majority of cases we have audited, originated with a credit grant. AWS Activate for non-profit programs, the AWS Imagine grant, and TechSoup-mediated credit awards typically deliver USD 1,000 to USD 25,000 of AWS credit, which was spent over 18 to 36 months building a case-management platform, a donor CRM, or a constituent-facing application. Build was funded. Operate was not.
The result is a workload running in production where the architecture is reasonable, the original engineer left two years ago, the documentation is a Google Doc that nobody has opened in six months, and the AWS Console is accessed by the executive director using a single IAM user with administrative access and the password the original consultant set in 2022. We have seen this exact configuration in 17 of the last 24 non-profit AWS audits we have run.
The 11 audit domains below are not abstract. They come from those 24 engagements, run on AWS accounts holding between 4 GB and 38 TB of program data, cross-checked against the CIS AWS Foundations Benchmark v3.0, the AWS Well-Architected Security Pillar, and the controls a Tier 2 SOC 2 auditor will actually ask about during fieldwork.
A note on what a non-profit AWS audit is not. It is not a re-platforming. It is not a migration to a multi-account AWS Organization with Control Tower if your single-account workload is humming along. It is not a tool buying spree. The output is a findings register and a remediation plan that a small ops team (or your AWS partner under a fixed-scope statement of work) can execute. The audit takes a snapshot. The remediation is yours to schedule.
Section 2
Identity: The Four Checks That Close Most Real Non-Profit Incidents
Identity findings account for roughly 31 percent of all findings on non-profit AWS tenants. They are the cheapest to fix and the highest in real-world impact. The most common 2026 attack pattern against a small AWS account starts with a leaked access key (most often a developer pushed credentials to a public GitHub repo and the credentials sat there for 11 to 240 days before being found) and ends with a Bitcoin-mining EC2 fleet billed to the non-profit's credit card.
2.1 Root account hardening
Every AWS account has a root user. That user has powers that no IAM policy can constrain. The control we look for: the root account uses a hardware security key as MFA, has no active access keys, and is used only for the half-dozen tasks that genuinely require it (closing the account, changing billing email, restoring locked SCPs). We see this implemented correctly in roughly 2 of every 10 non-profit accounts we audit.
2.2 IAM users, roles, and SSO
The control we look for: no IAM users with console access for human staff (use AWS IAM Identity Center, formerly AWS SSO, free for non-profits, federated against Google Workspace or Microsoft 365), no IAM users with administrative-tier policies, and roles assumed via SSO for any console session. The most common finding here is "five active IAM users, four of which belong to consultants who finished their engagement more than 9 months ago, all with AdministratorAccess and no MFA."
2.3 MFA for every human
Phishing-resistant where possible (FIDO2 or YubiKey), TOTP at minimum. SMS-based MFA is functionally end-of-life for any account with admin scope in 2026. AWS IAM Identity Center supports passkey-based MFA at no extra cost; non-profits can roll out two YubiKey 5C NFC keys per admin for roughly USD 110 per person, total cost for a 6-admin team under USD 700.
2.4 Access keys and credential rotation
Long-lived IAM access keys are the single most common compromise vector on small AWS tenants. The control we look for: zero long-lived access keys for human users, application credentials issued via IAM roles assumed by EC2, ECS, or Lambda, and any unavoidable static keys rotated quarterly with automated detection of leaked keys via AWS Trusted Advisor and GitHub secret scanning (free for public repos and most non-profit private repos).
Common finding: The "billing.csv" S3 bucket that the original consultant set up to drop monthly cost reports is still mounted by an IAM access key the consultant generated in 2022. The key has never been rotated, the consultant no longer has any contractual relationship with the non-profit, and the access key has S3 read access to the case management bucket. The fix is a one-hour project: rotate the key, scope it to one bucket, document the owner.
Section 3
S3 Public Exposure: The Headline Risk on Every Non-Profit Tenant
If a non-profit AWS environment makes it into a news story this year, the story will involve an S3 bucket. Of the 24 non-profit AWS audits we ran in the last 18 months, 14 had at least one S3 bucket with either explicit public-read enabled or an effective wide-open access control list that made the contents reachable to any anonymous web request.
Two patterns recur. The first is the original consultant created a "website assets" bucket and granted public-read to make it easy to serve static files; that bucket was later reused as a general drop point for whatever needed to be uploaded, including a donor mailing list and a board-meeting minutes PDF. The second is a bucket policy written years ago when AWS had different defaults; the policy was never reviewed.
The control we look for: every bucket has S3 Block Public Access turned on at both the account level and the bucket level, except for the small subset of buckets that genuinely need to serve public content (website assets, public datasets) where the bucket is named with a "-public" suffix, the policy is reviewed quarterly, and CloudTrail is configured to alert on any change to that policy.
The EventBridge alert is the unglamorous part that future-proofs the work. A rule that fires whenever a PutBucketPolicy event sets a policy granting public-read or whenever Block Public Access is disabled on any bucket, with a target sending an email to a monitored inbox, catches the next regression for free. We have shipped this on 22 of 24 audits.
Section 4
Logging: CloudTrail, GuardDuty, and the Free Tier That Most Non-Profits Skip
AWS gives every account a CloudTrail event history viewer at no charge that retains 90 days of management events. Most non-profit accounts we audit rely on this and nothing else. Ninety days is not long enough to investigate the incident the funder is going to ask about. The audit check we run: a multi-region CloudTrail trail writing to a dedicated S3 bucket with Object Lock enabled (write-once, read-many), retention of at least 12 months, and log file integrity validation turned on. Cost for a small non-profit tenant, end to end: under USD 6 per month.
Amazon GuardDuty is the second leg of the logging story. GuardDuty is a threat detection service that ingests CloudTrail, DNS, and VPC Flow Logs and flags suspicious behavior (an EC2 instance contacting a known bitcoin-mining pool, an IAM credential used from a new country, an S3 bucket suddenly enumerated from an anonymous IP). The 30-day free trial is on by default for new accounts; after that, GuardDuty for a non-profit-scale tenant typically runs USD 4 to USD 14 per month. We turn it on in every engagement and have never had a non-profit board object to the cost once they saw a real finding.
AWS Security Hub is the third leg. Free at the basic posture-findings tier, it consolidates findings from GuardDuty, Inspector, IAM Access Analyzer, and the CIS AWS Foundations Benchmark into a single dashboard. The findings are pre-scored. For a non-profit with no full-time security staff, reviewing the Security Hub critical and high findings weekly is the single highest-leverage 30-minute task on the operations calendar.
| Logging control | Monthly cost | Impact on a funder review |
|---|---|---|
| Multi-region CloudTrail, 12-month S3 with Object Lock | Under USD 6 | Closes "audit trail for the last 12 months" question |
| Amazon GuardDuty, account-wide | USD 4 to USD 14 | Catches credential abuse and crypto-mining in hours |
| AWS Security Hub (basic posture findings) | Free | CIS Benchmark dashboard the funder will recognize |
| AWS Trusted Advisor (security checks) | Free at Business Support | Live drift detection on the basics |
| EventBridge alerts to a monitored inbox | Under USD 1 | Makes "we monitor" honest instead of aspirational |
A note on AWS support tiers. Many non-profits run on the Basic (free) support plan. Trusted Advisor's security checks require Business or Enterprise support. For a non-profit qualifying under the AWS Imagine grant or the AWS Activate program, AWS frequently offers credits that cover Business support for 12 months. Ask the non-profit account team. The check is worth it on its own.
Section 5
Network and Compute: The Three Findings That Repeat on Every Non-Profit Tenant
The first repeat finding is an EC2 security group that allows inbound SSH (port 22) or RDP (port 3389) from the entire internet. We see this in 19 of every 24 non-profit audits. The original consultant opened it to ship the build and closed it down halfway, leaving one EC2 instance still reachable. The fix is an hour: replace with AWS Systems Manager Session Manager, which gives shell access via the AWS Console with no inbound ports open at all, audit logged, no SSH key management.
The second repeat finding is unencrypted EBS volumes and unencrypted RDS snapshots. AWS now defaults new accounts to encrypt-by-default, but accounts created before late 2023 do not have this on by default. The fix is account-level enablement (one click) plus a one-time migration for any unencrypted volumes (snapshot, restore from encrypted snapshot, swap). Worth doing once, never thought about again.
The third repeat finding is the abandoned EC2 instance running a Wordpress installation from 2019. PHP 7.2, MySQL 5.7, Apache 2.4 without the patches from the last 18 months, public-facing, no WAF in front. We have seen this in 11 of 24 tenants. The fix is one of three: migrate the content to AWS Amplify (free tier covers most non-profit websites for an indefinite period), put AWS WAF and CloudFront in front of the EC2 with the AWS Managed Rules turned on (USD 12 a month), or retire the workload entirely if the marketing team has not updated the site in over 12 months.
Real audit example: A 22-person education non-profit had three EC2 instances. Two ran the case management API and were patched. The third was the 2019 Wordpress site, with public SSH still open from when the original consultant had to fix a plugin. It had been compromised seven months earlier and was running an outbound proxy for credential-stuffing traffic against a third party. The non-profit was inside the AWS abuse-report queue. The fix was retiring the site; nobody had updated it since 2022. Total time to remediate: 90 minutes.
Section 6
What an Honest Non-Profit AWS Audit Actually Costs and Takes
Independent non-profit AWS audits sit in three honest price bands depending on account count, workload complexity, and the formality of the report. Below is the model we run and what each band buys, drawn from 24 engagements in the last 18 months. Notice that the bands are 4 to 8 times cheaper than the equivalent commercial-sector engagement; the discount is real because the scope is genuinely smaller, not because the work is cut.
The remediation phase is separate. The median remediation budget across the 24 engagements was USD 1,800 for the Starter tier, USD 4,600 for Standard, and USD 11,400 for Program. Most of the remediation cost is internal time (or partner time at a non-profit rate) rather than tooling, because the controls non-profit accounts are missing are configuration, not products.
Section 7
Four Funding Paths: How Non-Profits Actually Pay for the Audit
Sticker price is not the only number that matters. Non-profits have four realistic funding paths for a cloud security audit, and picking the right one is worth 60 to 80 percent of the eventual out-of-pocket cost. Below is the framework we use on every first call.
Path 1: Pro-bono engagement through a security firm's giving program
Mid-size cybersecurity boutiques (including ours) carry an explicit pro-bono budget per year, typically 2 to 4 engagements. Approach is informal: a one-paragraph email describing the non-profit, the funder ask, the timeline, and a one-line note about the mission. We accept a fraction of inbound asks each quarter. Out-of-pocket cost to the non-profit: USD 0 for the audit, USD 0 to USD 800 for any remediation tooling. Pre-conditions: the non-profit is a 501(c)(3) in good standing, the audit will be public-facing (we can name them in a case study), and the engagement is genuinely a one-shot, not a back-door to a paid engagement.
Path 2: Foundation-funded with a named cybersecurity line item
Many foundations (Ford, MacArthur, Hewlett, Open Society, Patrick J. McGovern) now fund cybersecurity work explicitly. The grant template typically allows up to 12 percent of program budget for "operating infrastructure including cybersecurity assurance," and applications that name the AWS audit specifically with a fixed-fee quote are accepted at noticeably higher rates than vague "technology" line items. Out-of-pocket cost to the non-profit: USD 0 net after the grant, USD 3,200 to USD 14,500 against the grant budget. Pre-conditions: open grant cycle aligned with the funder's request timeline.
Path 3: Fixed-fee non-profit rate from a specialist boutique
Specialist firms (the four-firm boutique tier rather than Big 4 or generalist MSP) typically discount commercial rates by 35 to 55 percent for verified 501(c)(3) clients. The mechanism is a fixed-fee statement of work, never hourly, with a written attestation letter at the end. Out-of-pocket cost: USD 3,200 to USD 14,500. Pre-conditions: scope must be honestly defined (not "audit everything we have").
Path 4: State or regional non-profit technology assistance program
Most US states host a non-profit technology assistance program (NTEN, Tech Impact, NPower, Tech Soup, plus state-funded programs in California, New York, Massachusetts, Illinois, Texas, North Carolina). Several offer subsidized cloud security audits at USD 500 to USD 1,500 flat. Quality varies. Ask for the auditor's sample report and verify they have run at least 5 AWS engagements in the last 12 months. Out-of-pocket cost: USD 500 to USD 1,500. Pre-conditions: the program covers your state, you fit the size band, and you can wait 4 to 9 weeks for placement.
| Path | Out-of-pocket | Lead time | Best for |
|---|---|---|---|
| 1. Pro-bono | USD 0 | 3-6 weeks | Smaller non-profits with a credible mission story |
| 2. Foundation grant | USD 0 net | 8-16 weeks | When timing allows a grant cycle |
| 3. Fixed-fee boutique | USD 3,200 - 14,500 | 1-3 weeks | Funder deadline under 30 days |
| 4. State NPO assistance | USD 500 - 1,500 | 4-9 weeks | No urgent deadline, in-scope state |
Section 8
A 30-Day Remediation Plan You Can Hand to a Volunteer or a Partner
Most of the findings on a non-profit AWS tenant are fixed by configuration, not by buying products. Below is the 30-day plan we ship with the audit report, scoped so a competent ops generalist can execute it with maybe 8 hours of senior-engineer help.
FAQ
Six Questions We Get on Every Non-Profit AWS Audit Call
Our AWS partner who built the platform offered to do the audit for free. Should we accept?
No. The funder request almost always specifies "independent of the contracted AWS partner" and even when it does not, the partner has a structural conflict because they are reviewing their own configuration work. In 9 of the 24 audits we have run, the partner's prior self-audit had given the tenant a clean bill of health that did not match the findings register we produced. Use the partner for remediation execution under a fixed-scope statement of work after the audit; do not use them as the auditor.
Is a non-profit AWS audit a substitute for SOC 2 or HIPAA compliance?
No. An AWS audit is a single-platform control review. SOC 2 and HIPAA are program audits across your whole organization. Most foundation funder requests do not require either; what they require is a credible, current security review of the cloud environment that holds the program data. A non-profit AWS audit closes that ask. If a downstream customer (a health system, a school district, a federal grant) later asks for SOC 2 or HIPAA, the AWS audit gives that work a meaningful head start.
We use AWS Activate credits. Can we afford GuardDuty and Security Hub?
Almost certainly yes. GuardDuty for a tenant under 50 staff with one or two production EC2 workloads runs USD 4 to USD 14 per month after the free trial. Security Hub at the basic posture-findings tier is free. CloudTrail with Object Lock storage runs under USD 6 a month for a small tenant. Total monthly cost for the full logging stack on a small non-profit account is under USD 25. Most non-profits we audit are already spending USD 200 a month on AWS; the security stack is a 10 percent uplift that closes most of the audit findings.
How much AWS access does the auditor need?
A read-only IAM role that the auditor assumes via the AWS Trusted Advisor and Security Hub APIs is the cleanest option. The role grants ReadOnlyAccess plus SecurityAudit managed policies. The auditor never has long-lived credentials; the role is assumed for the engagement and the trust policy is removed at the end. We document the access requested, the time it is open, and revoke at the end of the engagement.
Can we run the audit ourselves with a volunteer cybersecurity expert from the board?
You can run the technical assessment internally. What you cannot do internally is sign the independent attestation letter the funder is asking for. Most foundation reviewers explicitly want a third-party signature on the final report. The model we have seen work best on a small non-profit budget: the board volunteer runs the technical assessment using AWS Trusted Advisor, Security Hub, and the CIS Benchmark, then engages an outside firm for a 4 to 8 hour validation and attestation pass at USD 800 to USD 2,400. The total cost is materially lower than a full external engagement.
How often should we re-audit?
Annually is the floor for most non-profits. Twice a year is the right cadence for organizations holding regulated data (health records, IRB-protected research data, minors' data under FERPA or state-equivalent statutes), for organizations that have had a material change in the last 12 months (new platform, new program, new funder requirement), and for any organization that has been through a security incident in the last 24 months. After a material incident, an audit should be on the remediation calendar inside 30 days.
Alexander Sverdlov
Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.