SAQ Response Workbook
Last updated: 2026-02-23
| Requirement | Applicable? | Comment |
|---|---|---|
| 1. Verify documentation and justification of all the application's trust boundaries, components, and significant data flows. | Yes | Trust boundaries, core components, and major data flows are documented and maintained as part of the security review process. |
| 2. Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | Yes | The application uses a modern web stack and does not rely on deprecated client-side plugin technologies. |
| 3. Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client. | Yes | Access control is enforced server-side at trusted enforcement points, and client-side checks are treated as UX only. |
| 4. Verify that all sensitive data is identified and classified into protection levels. | Yes | Sensitive data is classified into defined protection levels and handled according to those classifications. |
| 5. Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture. | Yes | Each protection level has associated security requirements, and those requirements are reflected in architecture and operational controls. |
| 6. Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet. | Yes | Integrity protections are in place through supply-chain controls and dependency governance, and untrusted runtime code loading is restricted. |
| 7. Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change. | Yes | DNS/subdomain takeover risk is recognized and partially controlled, with additional automated monitoring planned to strengthen coverage. |
| 8. Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks. | Yes | Anti-automation protections are implemented through layered rate limits and abuse controls on public and sensitive flows. |
| 9. Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions. | Yes | Untrusted uploaded files are stored in managed storage with scoped permissions and controlled access boundaries. |
| 10. Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content. | Yes | Antivirus/malware scanning is currently a known gap and is tracked for remediation, with compensating controls in place in the interim. |
| 11. Verify API URLs do not expose sensitive information, such as the API key, session tokens etc. | Yes | Sensitive credentials are not exposed in API URLs, and secret handling is restricted to safer transport mechanisms. |
| 12. Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions. | Yes | Authorization is enforced at both route/controller level and resource ownership/permission level for defense in depth. |
| 13. Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources. | Yes | HTTP methods are restricted and validated against actor and action context to prevent unauthorized method use. |
| 14. Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts. | Yes | Build and deployment are automated and repeatable through documented CI/CD and deployment procedures. |
| 15. Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion. | Yes | Redeployment is runbook-driven and automatable, and backup/restore timing validation is tracked as an operational evidence item. |
| 16. Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering. | Yes | Security-relevant configuration integrity is checked through policy enforcement and automated drift/tamper detection workflows. |
| 17. Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures. | Yes | Production hardening disables debug-oriented behavior and reduces disclosure surfaces in runtime responses. |
| 18. Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker. | Yes | Authentication and authorization decisions are not based on the Origin header and instead rely on trusted credentials and server-side validation. |
| 19. Verify that user set passwords are at least 12 characters in length | Yes | User-set password policy enforces a minimum length of 12 characters. |
| 20. Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password. | Yes | Initial verification secrets are securely generated, short-lived, and not used as long-term passwords. |
| 21. Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash. | Yes | Password storage is handled by the authentication platform using hardened password storage practices, and provider attestation is maintained for final audit evidence. |
| 22. Verify shared or default accounts are not present (e.g. "root", "admin", or "sa"). | Yes | Shared/default user authentication accounts are not used in production, and privileged access is role-based and controlled. |
| 23. Verify that lookup secrets can be used only once. | Yes | Lookup secrets used in verification flows are one-time use and cannot be replayed after consumption. |
| 24. Verify that the out of band verifier expires out of band authentication requests, codes, or tokens after 10 minutes. | Yes | Out-of-band expiry controls are implemented, with one flow currently exceeding 10 minutes and tracked for alignment. |
| 25. Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient). | Yes | Initial authentication codes/tokens are generated using secure randomness and meet practical entropy requirements. |
| 26. Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. | Yes | Logout and session expiry invalidate active sessions to prevent unauthorized session continuation. |
| 27. Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties. | Yes | Users can terminate other active sessions after password changes, including reset and recovery paths. |
| 28. Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations. | Yes | User access is session-token based, while static secrets are limited to internal service trust boundaries. |
| 29. Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications. | Yes | Sensitive actions require a valid authenticated session and, where appropriate, elevated assurance such as MFA. |
| 30. Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed. | Yes | Access control is enforced in trusted backend layers to remain effective even if client-side controls are bypassed. |
| 31. Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized. | Yes | Authorization attributes are validated server-side, and unauthorized user manipulation of policy inputs is prevented. |
| 32. Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. | Yes | Least-privilege controls are enforced through scoped permissions, ownership checks, and privilege boundaries. |
| 33. Verify that access controls fail securely including when an exception occurs. | Yes | Access control behavior is fail-closed, including error and exception paths. |
| 34. Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records. | Yes | IDOR risk is mitigated through strong object ownership and authorization checks across CRUD operations. |
| 35. Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use. | Yes | Administrative interfaces require MFA-level assurance for privileged operations. |
| 36. Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables). | Yes | Defensive request validation is in place, and explicit duplicate-parameter/HPP test coverage is being expanded. |
| 37. Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | Yes | User input entering mail workflows is validated and constrained, with periodic injection-focused testing recommended. |
| 38. Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. | Yes | Dynamic code execution patterns such as eval are avoided in application runtime logic. |
| 39. Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports. | Yes | SSRF protections use strict outbound validation, allowlisting, and network-level destination controls. |
| 40. Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject. | Yes | Scriptable SVG content is not accepted on upload surfaces that handle untrusted user files. |
| 41. Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). | Yes | Context-appropriate output handling is applied, including framework escaping and explicit sanitization for rich HTML rendering paths. |
| 42. Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. | Yes | JSON processing uses parser-based handling and strict content-type validation, with no JSON eval behavior in runtime paths. |
| 43. Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. | No | LDAP is not used by this application, so this control is not applicable in the current architecture. |
| 44. Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR. | Yes | Sensitive private data has encryption-at-rest controls, with provider attestations used for managed infrastructure evidence. |
| 45. Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | Yes | Constant-time comparison techniques are used for secret validation, and coverage is being expanded across all relevant crypto checks. |
| 46. Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically-secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable. | Yes | Identifiers are generated with CSPRNG-backed primitives, including UUIDv4 where applicable. |
| 47. Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. | Yes | Key material isolation is a known improvement area, and migration toward vault-backed cryptographic operations is planned. |
| 48. Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. | Yes | Logging standards prohibit credentials and payment details in logs, and redaction/minimization controls are in place with periodic verification needed. |
| 49. Verify the application protects sensitive data from being cached in server components such as load balancers and application caches. | Yes | Sensitive responses are marked to prevent intermediary caching, with explicit policy controls for no-store behavior. |
| 50. Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data. | Yes | Browser storage is limited to non-sensitive state, and sensitive authentication data is not intentionally persisted in insecure client storage. |
| 51. Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data. | Yes | Sensitive data is primarily sent in headers/body, with limited signed token link patterns retained for verification flows and controlled via expiry and scope. |
| 52. Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required. | Yes | Access to sensitive and privileged operations is audited with logging designed to avoid capturing sensitive payload content. |
| 53. Verify that connections to and from the server use trusted TLS certificates. Where locally generated or self-signed certificates are used, the server must be configured to only trust specific local CAs and specific self-signed certificates. All others should be rejected. | Yes | Production traffic is protected with trusted TLS and HTTPS-first controls, with hosting-provider trust posture captured as audit evidence. |
| 54. Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | Yes | Certificate revocation and stapling controls are handled at the hosting/platform layer and should be confirmed via provider attestations. |