Security, privacy, and accessibility
Application Security Requirements Checklist for Software Buyers
A buyer-focused framework for turning “make it secure” into risk-based requirements, observable acceptance evidence, and continuing ownership after launch.
Published by Kennedy Gichobi · Expert-reviewed by Kennedy Gichobi · Published · 1516 words
Begin with business risk instead of a generic promise
“The application must be secure” cannot be designed, estimated, or accepted because it does not identify what needs protection or what evidence will demonstrate protection. Start with the people, information, actions, and business consequences involved. A public brochure, an employee scheduling tool, a client document portal, and a healthcare workflow do not require identical controls. Their exposure, users, data sensitivity, availability needs, legal obligations, and likely abuse differ materially.
Write a short risk profile before selecting requirements. Identify sensitive data, privileged actions, payment or identity functions, external users, integrations, regulatory context, expected scale, and the harm caused by unauthorized access, alteration, disclosure, or downtime. Record assumptions and approved exceptions. NIST’s Secure Software Development Framework recommends identifying and evaluating security requirements and risks during design, maintaining the associated decisions, and applying greater rigor to higher-risk areas rather than treating security as a checklist added at release.
Define ownership, environments, and the system boundary
The requirements should state which organization controls the source repository, cloud project, production data, domain, deployment service, monitoring, backups, and external accounts. Developers can administer client-owned resources without personally owning them. Require individual access, multifactor authentication, least privilege, and a documented recovery path for critical services. Separate production from development and testing so ordinary engineering work does not require unrestricted production access or copies of sensitive customer data.
Create a simple system boundary showing browsers or mobile clients, application services, databases, file storage, background jobs, administrators, and third-party systems. Mark which data crosses each boundary and which party is responsible. Include analytics, email, support tools, AI services, payment providers, and spreadsheet exports; risk often escapes through tools omitted from the architecture diagram. Define approved production regions, retention constraints, and whether vendors may use the information for their own purposes before code makes those decisions difficult to reverse.
Protect data, secrets, uploads, and integrations
Classify information so controls follow its sensitivity. State which data is required, where it is stored, how long it remains, who may export it, how deletion works, and what backups retain. Require encrypted network transport and appropriate encryption at rest, while recognizing that encryption does not correct excessive access. Prevent sensitive values from appearing in URLs, analytics events, client-side logs, error messages, or unsecured support attachments. Use synthetic or de-identified information for routine testing whenever possible.
Credentials, API keys, signing keys, and database passwords belong in managed secret storage with restricted access and rotation procedures—not source code, chat, or frontend configuration. Validate untrusted input and encode output according to context. For file uploads, define allowed types and sizes, storage isolation, authorization, safe filenames, malware or content inspection where warranted, and behavior when processing fails. For integrations, verify incoming messages, restrict outbound credentials, handle retries without duplicate transactions, validate remote data, and expose failures to operators instead of silently losing work.
Require useful security logs and operational visibility
An application cannot support investigation if it records only technical errors or, conversely, logs sensitive content indiscriminately. Define auditable events such as authentication attempts, account recovery, multifactor changes, role and permission changes, administrator access, exports, deletion, payment actions, security-setting changes, and important integration failures. Logs should contain time, actor, action, relevant object, outcome, and request context without passwords, session tokens, full payment data, or unnecessarily sensitive record content.
Protect logs from ordinary user alteration, restrict who can read them, retain them according to risk, and make important events searchable. Establish alerts for conditions that need attention and document who receives them. CISA’s Secure by Demand guidance tells software customers to ask for security logs covering identity, configuration, data access, and business-relevant actions; its small-business guidance emphasizes logging as a practical way to detect and understand suspicious behavior. Acceptance should include retrieving a representative event, not merely confirming that “logging exists.”
Address dependencies, builds, and software supply-chain risk
Modern applications depend on open-source packages, hosted services, build systems, container images, and platform components. Require an inventory of important dependencies and a process for monitoring known vulnerabilities, support status, and incompatible updates. Lock and review dependency changes, protect the build and deployment workflow, and restrict who can release production versions. A dependency scanner creates signals; the requirement must also assign responsibility for triage, remediation, documented risk acceptance, and replacement when a component reaches end of life.
Protect source branches and review changes in proportion to risk. Keep development credentials separate from production. Generate deployments through a repeatable build process rather than an undocumented laptop procedure. Preserve enough release information to identify what version is running and roll back safely. NIST groups secure-development work into preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. A proposal that mentions code scanning but omits environments, release integrity, ownership, and response covers only one part of that lifecycle.
Turn requirements into verification and acceptance evidence
Security acceptance should connect each important requirement to evidence. Evidence may include design review, configuration inspection, automated tests, manual abuse cases, dependency results with triage, access reviews, a restored backup, a log demonstration, or an independent assessment appropriate to the system’s risk. Do not accept a scanner’s clean summary as proof of every control. Scanners cannot determine whether a manager can access the wrong organization, whether a recovery process exposes an account, or whether operators know how to respond.
The OWASP Application Security Verification Standard provides a commercially usable set of web-application requirements and a basis for specifying verification in procurement and contracts. Select a risk-appropriate scope and reference the exact ASVS version and requirement identifiers instead of claiming vague “OWASP compliance.” Record which requirements apply, which do not, and why. The goal is traceability from risk to requirement to implementation to evidence, not a badge. Re-test critical boundaries after material identity, payment, data, or architecture changes.
Plan incident response, backups, updates, and handover
Security responsibilities continue after launch. Define how vulnerabilities are reported, who evaluates them, how severity affects response, how users are notified when appropriate, and how emergency changes are tested and documented. Establish monitoring ownership, backup scope, restoration objectives, recovery contacts, and a schedule for testing a representative restoration. Include dependency updates, platform upgrades, access review, certificate or domain renewal, and removal of stale accounts in the maintenance arrangement.
The business should receive current source access, deployment instructions, service inventory, data-flow overview, administrator and recovery procedures, known risks, outstanding findings, backup instructions, and the ability to export its data. The agreement should support revoking the former developer’s access and transferring work to another qualified engineer. Responsible handover is itself a security control: a technically strong application can still become vulnerable when only one person knows how to operate, update, or recover it.
Apply the checklist to a concrete client-portal scenario
Imagine a portal where customers upload documents, staff process requests, managers approve exceptions, and administrators manage organizations. The risk profile identifies confidential files, cross-organization isolation, privileged approvals, email invitations, and availability during business hours. Requirements cover verified invitations, multifactor protection for administrators, server-side organization checks, scoped storage paths, short-lived download authorization, upload restrictions, role-change logs, approval history, backup restoration, and alerts for repeated access failures.
Acceptance then demonstrates that one customer cannot retrieve another organization’s file even with a guessed identifier; a disabled staff account loses access; an administrator role change appears in an immutable audit trail; secrets are absent from the client bundle; a representative backup restores into an isolated environment; integration retries do not create duplicate requests; and the owner can deploy or hand the documented system to another engineer. This evidence is far more meaningful than a proposal that simply lists encryption, authentication, and a vulnerability scan.
Use the checklist when evaluating a developer or proposal
Before approving a build, confirm that security requirements are risk-based and written; repositories and production accounts are client-controlled; environments and sensitive data are separated; identity recovery and authorization boundaries are explicit; secrets, uploads, integrations, and exports have defined controls; important actions are logged; dependencies and builds are managed; backups are restorable; verification evidence is tied to requirements; incident and maintenance responsibilities are assigned; and handover preserves business ownership.
Ask candidates to walk through one failure or abuse case instead of answering whether they “follow best practices.” A strong developer should clarify actors, assets, boundaries, consequences, verification, and operating responsibility before choosing controls. No checklist guarantees that software will never fail or be attacked. It makes risk visible, turns expectations into testable work, and creates a shared basis for cost and acceptance. Use the project questionnaire to describe your users, sensitive information, critical actions, integrations, and consequences so the security scope can be planned with the product rather than attached afterward.
Authoritative references
Related software planning guides
- Application Security Implementation Roadmap for Product Owners
- Privacy Engineering Requirements Checklist for Custom Software
- Software Developer Security Due Diligence for Product Owners