Security Audit Checklist for Web Applications and SaaS (2025)

A security audit is a systematic evaluation of your organization's security posture. Done properly, it identifies gaps before attackers do. Done poorly, it's a checkbox exercise that creates false confidence.

This checklist covers the key areas across a comprehensive security audit. Use it as a self-assessment, pre-audit preparation, or as the basis for an internal security review.

1. Access Control and Identity

Authentication

□ Multi-factor authentication (MFA) enforced for all users
□ MFA enforced for all administrative and privileged accounts
□ Password policy: minimum length, complexity, breach detection
□ Passwords hashed with bcrypt/Argon2/scrypt (not MD5/SHA-1)
□ Account lockout after failed login attempts
□ Session tokens use cryptographically secure random values
□ Sessions expire after inactivity (≤8 hours for sensitive apps)
□ Sessions invalidated on logout and password change
□ Authentication events logged (success, failure, MFA bypass)
□ No default/shared credentials in any system

Authorization

□ Role-based access control (RBAC) implemented
□ Principle of least privilege applied to all accounts
□ No standing privileged access — use JIT (just-in-time)
□ Horizontal access control: users can't access other users' data
□ Vertical access control: non-admins can't access admin functions
□ API endpoints enforce authorization (not just authentication)
□ Authorization enforced server-side (not relying on client-side UI hiding)
□ Access reviews conducted quarterly for privileged accounts
□ Offboarding process revokes access within 24 hours

Third-Party Access

□ Inventory of all third-party services with access to systems/data
□ Data Processing Agreements (DPAs) in place for all processors
□ Third-party access uses unique credentials (not shared accounts)
□ Vendor access logged and reviewed
□ Vendor security assessments for critical suppliers

2. Network Security

□ TLS 1.2+ enforced on all external endpoints (TLS 1.0/1.1 disabled)
□ HSTS enabled with appropriate max-age
□ Security headers set: CSP, X-Content-Type-Options, X-Frame-Options
□ External attack surface mapped (all internet-facing services documented)
□ Unnecessary ports and services disabled
□ Firewall rules reviewed — default deny with explicit allows
□ No management interfaces (SSH, RDP, admin panels) directly internet-exposed
□ VPN or ZTNA for remote access to internal systems
□ Network traffic logged and monitored
□ WAF deployed in front of web applications
□ DDoS protection in place

3. Data Protection

□ Data classified by sensitivity
□ Sensitive data encrypted at rest (AES-256)
□ All data encrypted in transit (TLS)
□ Encryption keys managed separately from data
□ Key rotation policy defined and implemented
□ Sensitive data minimization — only collecting what's needed
□ Data retention policy documented and enforced
□ Data deletion process (including backups) verified
□ No sensitive data in logs (PII, passwords, tokens)
□ Backups encrypted and tested for restorability
□ Backup access controls equivalent to production

4. Application Security

□ Input validation on all user-supplied data
□ Parameterized queries / ORM used (no string concatenation in SQL)
□ Output encoding to prevent XSS
□ CSRF protection on all state-changing requests
□ Content Security Policy implemented and tested
□ Dependency scanning in CI/CD (npm audit, Snyk)
□ No secrets in source code or repositories
□ Secure coding guidelines followed and enforced in review
□ SAST (static analysis) tool in CI/CD pipeline
□ DAST (dynamic analysis) / vulnerability scanning in staging
□ API endpoints rate-limited
□ API authentication required on all non-public endpoints
□ Error messages don't expose internal details (stack traces, SQL errors)
□ File upload validation: type, size, content scanning
□ SSRF prevention on any server-side URL fetching

5. Cloud Infrastructure

□ Cloud account root/admin access MFA-protected
□ No long-lived IAM access keys (use IAM roles)
□ IAM roles follow least privilege
□ Public S3 buckets: documented and intentional (Block Public Access enabled by default)
□ S3 encryption at rest enabled
□ Security groups: no 0.0.0.0/0 for SSH, RDP, or admin ports
□ CloudTrail / audit logging enabled in all regions
□ AWS Config / GCP Security Command Center enabled
□ GuardDuty / Security Command Center threat detection enabled
□ Unused resources removed (reduces attack surface and cost)
□ Resource tagging policy for ownership accountability
□ Multi-account strategy for environment separation
□ Infrastructure as Code used (reproducible, auditable deployments)

6. Endpoint Security

□ All corporate devices enrolled in MDM
□ Full-disk encryption enabled (FileVault, BitLocker)
□ EDR deployed on all endpoints
□ Operating system patching: all endpoints within 30 days of critical patches
□ Software patching: browsers, productivity apps, developer tools
□ Screen lock on inactivity (≤5 minutes)
□ USB/removable media policy enforced
□ Personal device policy (BYOD) documented
□ Remote wipe capability for corporate devices

7. Logging and Monitoring

□ Authentication events logged
□ Privileged access logged
□ Data access logged for sensitive data
□ Application errors logged
□ Cloud infrastructure events logged (CloudTrail, VPC Flow Logs)
□ Logs shipped to centralized, tamper-evident storage
□ Log retention: minimum 90 days hot, 1 year archive
□ Alerting on critical events (multiple auth failures, privilege escalation)
□ SIEM or log analysis platform in use
□ On-call rotation for security alerts
□ Metrics: MTTD (mean time to detect), MTTR (mean time to respond)

8. Vulnerability Management

□ External attack surface scanned regularly (weekly or continuous)
□ Internal vulnerability scans run monthly
□ Penetration test: annual for critical systems, quarterly for highly regulated
□ CVE feeds monitored for technologies in use
□ Vulnerability severity SLAs defined (Critical: 24–72h, High: 2 weeks)
□ Vulnerability tracking and remediation process documented
□ Compensating controls documented for accepted risks
□ Bug bounty or responsible disclosure program

9. Incident Response

□ Incident response plan documented and approved
□ IR team roles and contacts documented
□ Contact list current (including after-hours numbers)
□ Runbooks for common incident types
□ IR tabletop exercise conducted in last 12 months
□ Breach notification procedures documented
□ Legal counsel identified for breach response
□ Cyber insurance policy reviewed
□ Communication templates prepared
□ Post-incident review process defined

10. Compliance and Governance

□ Security policies documented and reviewed annually
□ Information security policy approved by leadership
□ Acceptable use policy in place
□ Vendor management policy
□ Security training completed by all staff (annual)
□ Security training for developers (secure coding)
□ GDPR privacy notices and data subject rights process (if applicable)
□ SOC 2 / ISO 27001 scope and controls documented (if pursuing)
□ Regulatory requirements identified for your industry
□ Risk register maintained and reviewed quarterly
□ Annual security review with executive leadership

Scoring Your Audit

After completing the checklist, categorize findings:

• Critical: Active security gap that could be immediately exploited → fix within 72 hours
• High: Significant gap with potential for material breach → fix within 2 weeks
• Medium: Control weakness, not immediately exploitable → fix within 90 days
• Low: Best practice not followed, minimal immediate risk → fix in next planning cycle
• Informational: Documentation, process, or tooling improvement → planned improvement

Produce a written report with findings, risk ratings, and a remediation roadmap. Repeating this audit annually lets you track improvement over time.