Security teams usually hear about a new application when it is days from go-live, with no record of what data it holds, who logs in, which machine credentials it uses or where it runs. This template is a ready-to-use intake questionnaire that a delivery team completes when a new application is proposed, built or bought. Its answers set a risk tier and route the application to the right level of review: baseline controls only, standard review, or full architecture review with threat modelling and testing. It covers in-house builds, bought software, SaaS and low-code applications. It is for application security teams, architects, delivery leads and anyone running a security review queue. AI use cases have their own form, the AI Use Case Intake Form Template; use both when a new application includes AI features.
How to use this template
- Copy sections 3 to 9 into your intake tool (form builder, service catalogue request or ticketing system). Keep the question IDs so routing rules in section 10 can run automatically.
- Replace text in square brackets, such as [Organisation], [application security team] and [N working days], with your own values. Bracketed thresholds and timelines are NHI Mgmt Group suggestions.
- Questions are written for a delivery lead or product owner, not a security specialist. "Don't know" is always allowed and routes to the more cautious path.
- Intake is triage, not assessment. The tiers should match the application risk classification in your policy. See section 5 of the Application Security Policy Template.
- Every completed questionnaire creates or updates an entry in the application inventory with an owner and tier.
1. Purpose
This questionnaire gives [Organisation] one entry point for every new application. It collects the facts needed to decide, within [3 working days], what security review the application needs, which teams must be involved and which baseline controls apply from day one. It records the application risk profile described in OWASP SAMM's Threat Assessment practice (Application Risk Profile stream), supports security categorisation under NIST SP 800-53 RA-2 and feeds the software and data inventories in NIST CSF 2.0 ID.AM-02 and ID.AM-07.
2. When the questionnaire is required
- Before a new application, service, SaaS product or low-code app is built, bought, piloted or connected to [Organisation] data, users or networks.
- When an existing application changes in a way that would change an answer: a new data category, a new user population (for example opening to customers), internet exposure, a new hosting model or a new integration.
- Small internal tools that only process public data and have no integrations may use the [short form: Parts A, B and D only].
3. Part A: Application and ownership
| ID | Question | Answer type |
|---|---|---|
| A1 | Application name and one-sentence description of what it does | Text |
| A2 | Business owner (accountable for risk) and technical owner (accountable for operation) | Names |
| A3 | How will it be obtained? | Built in-house / built by a supplier for us / bought and self-hosted / SaaS / low-code or citizen-developed / open source |
| A4 | Supplier or product name and contract owner, if any | Text |
| A5 | Target go-live date and whether it starts as a pilot | Date, yes or no |
| A6 | Which business process stops if the application is unavailable, and for how long can it be down? | Text; [under 4 hours / 1 day / 1 week / longer] |
4. Part B: Data
| ID | Question | Answer options |
|---|---|---|
| B1 | Highest classification of data the application will store or process | [Public / Internal / Confidential / Restricted] / don't know |
| B2 | Will it process personal data? Whose? | No / employees / customers / children / patients / other / don't know |
| B3 | Will it process special category data, criminal records data or government identifiers? | Yes / no / don't know |
| B4 | Will it store, process or transmit payment card data? | Yes / no / don't know |
| B5 | Approximate number of records or data subjects | [Under 1,000 / 1,000 to 100,000 / over 100,000] / don't know |
| B6 | Will data leave [Organisation] systems, for example to a supplier, a sub-processor or another country? | Yes (where) / no / don't know |
| B7 | What is the worst realistic outcome if the data were disclosed, altered or lost? | Minor / significant harm to people or [Organisation] / severe or regulatory |
B7 asks for impact on confidentiality, integrity and availability in plain language, the same three objectives FIPS 199 uses for security categorisation. See the Data Classification Guide. A "yes" to B2 with B3, or B5 over 100,000, triggers DPIA screening; see the DPIA Template.
5. Part C: Users and access
| ID | Question | Answer options |
|---|---|---|
| C1 | Who will log in? | Employees / contractors / partners or suppliers / customers or the public |
| C2 | How will users authenticate? | [Organisation] SSO / separate usernames and passwords / social login / customer identity platform / no login / don't know |
| C3 | Will MFA be enforced for all users, and for administrators? | All / administrators only / no / don't know |
| C4 | Are there different roles (for example user, approver, administrator)? Who grants them? | Text |
| C5 | Can it provision and remove accounts automatically from the [Organisation] directory (for example via SCIM)? | Yes / no / don't know |
| C6 | Will any supplier staff have administrative or support access to the application or its data? | Yes / no / don't know |
A "no" to C2 SSO for workforce users, or a "no" to C3 for administrators, is recorded as an exception that needs approval. See the SSO Integration Checklist and the Entitlement Catalogue and Application Onboarding Guide.
6. Part D: Machine identities, secrets and integrations
This part is the one most often skipped, and it is where the long-lived credentials behind many breaches are created. Answer it even for SaaS.
| ID | Question | Answer options |
|---|---|---|
| D1 | List the other systems the application will connect to, in each direction | Text (system, direction, purpose) |
| D2 | For each connection, what credential is used? | OAuth app or token / API key / service account with password / certificate / cloud workload identity / personal user account / don't know |
| D3 | Will any integration use a named person's account or personal token? | Yes / no / don't know |
| D4 | What permissions or OAuth scopes will each integration request? Does any request tenant-wide or admin scopes? | Text; yes / no |
| D5 | Where will secrets be stored? | [Organisation] secrets manager / platform-managed identity / configuration file or environment variable / in code / don't know |
| D6 | Who owns each credential, and how and how often is it rotated? | Text |
| D7 | Will the application expose an API or accept webhooks from outside [Organisation]? | Yes / no / don't know |
D3 "yes" or D5 "in code" or "configuration file" blocks approval until fixed. See the Secrets Management Guide, the Service Account Request Form Template and, for third-party connections, the SaaS Integration Security Questionnaire Template.
7. Part E: Hosting and exposure
| ID | Question | Answer options |
|---|---|---|
| E1 | Where will it run? | Supplier SaaS / [Organisation] cloud account / on-premises / end-user devices / mobile app store / don't know |
| E2 | Will it be reachable from the internet? | Yes, public / yes, behind SSO or VPN / internal only / don't know |
| E3 | Which cloud account, subscription or project, and who administers it? | Text |
| E4 | Will it send logs to [central logging or SIEM]? Which events (logins, admin changes, data exports)? | Yes / no / don't know; text |
| E5 | Is there a backup and restore plan that meets the downtime in A6? | Yes / no / supplier-managed / don't know |
8. Part F: Development and supply chain
Answer for in-house or supplier-built applications. For bought or SaaS products, answer F5 and F6 only.
| ID | Question | Answer options |
|---|---|---|
| F1 | Which source repository and CI/CD pipeline will be used? | Text |
| F2 | Are SAST, dependency scanning and secrets scanning enabled on the repository? | Yes / partly / no / don't know |
| F3 | Will AI coding assistants or agents contribute code? | Yes / no / don't know |
| F4 | Does the application include AI features (models, LLM calls, agents)? | Yes (complete the AI intake form) / no |
| F5 | What independent assurance does the supplier provide (for example ISO/IEC 27001 certificate, SOC 2 report, penetration test summary)? | Text |
| F6 | Is there a contract clause for security incident notification and vulnerability fixes? | Yes / no / don't know |
9. Part G: Declaration
- The business owner confirms the answers are accurate to the best of their knowledge and that they accept accountability for the application's risk.
- The technical owner confirms they will update the questionnaire when an answer changes.
- Both confirm the application will not go live before the route in section 10 is complete or an exception is approved.
10. Tiering and routing rules
| Tier | Triggered by any of | Route and required activities |
|---|---|---|
| Tier 1 (high) | B1 Restricted; B3 or B4 yes; B5 over 100,000; B7 severe; C1 customers or public with E2 public; D4 tenant-wide or admin scopes; A6 under 4 hours | Full architecture review and threat model; penetration test before go-live; ASVS Level 2 baseline at minimum, Level 3 where [policy] requires; DPIA screening; supplier assessment |
| Tier 2 (medium) | B1 Confidential; B2 personal data; C6 yes; D7 yes; E2 public behind SSO; F3 yes | Standard design review; abuse case review for exposed features; ASVS Level 2 baseline; supplier questionnaire if bought |
| Tier 3 (low) | None of the above, and no "don't know" answers in Parts B to E | Baseline controls checklist and inventory entry only; [application security team] spot checks |
| Blocked until fixed | D3 yes; D5 in code or configuration file; C2 separate passwords for workforce users without approved exception | Fix or approved exception before review continues |
Any "don't know" in Parts B to E moves the application up one tier until it is answered. OWASP ASVS 5.0 groups its requirements into three levels; in the local copy of version 5.0.0 there are 70 Level 1, 183 Level 2 and 92 Level 3 requirements. See the Application Security Requirements from ASVS and the Security Architecture Review Guide.
Implementation guidance
Rolling it out
- Put the questionnaire where requests already start: the project approval gate, the procurement request or the cloud account request. A form nobody is routed to will not be used.
- Pilot with [two] delivery teams for [one quarter]. Time completion; if it runs much over [30 minutes], cut questions rather than adding help text.
- Automate the routing rules so the requester sees a provisional tier and timeline as soon as they submit.
- Pass the answers forward: Part D becomes the starting list for the threat model's data flows and trust boundaries (see the Threat Model Template), and Parts C and E become the scope for any penetration test (see the Penetration Test Scoping Checklist).
- Re-run intake on the change triggers in section 2 and at least [annually] for Tier 1 applications.
Small and large organisations
| Situation | Adjustment |
|---|---|
| Small team, few applications | Use Parts A, B, C and D only, with two tiers (review or baseline) |
| Large portfolio | Load answers into the application inventory or CMDB and drive control requirements, scan coverage and review dates from the tier |
| Mostly SaaS | Weight Parts C, D and F5 and F6; combine with third-party risk intake so suppliers are assessed once |
| Mostly in-house builds | Weight Parts D and F; link the repository so scan results attach to the inventory entry |
Measuring it
- Intake coverage: share of applications going live with a completed questionnaire.
- Discovered outside intake: applications found by SaaS discovery, cloud inventory or SSO logs with no questionnaire, per quarter.
- Median time from submission to tier decision.
- Re-tiering rate: applications moved up a tier after review found a missed answer.
- Blocked answers fixed: share of D3 and D5 blocks resolved without an exception.
Framework mapping
| Questionnaire part | Mapping |
|---|---|
| A, inventory entry | NIST CSF 2.0 ID.AM-02 |
| B (data) | NIST CSF 2.0 ID.AM-07; NIST SP 800-53 RA-2; FIPS 199 |
| D (connections and credentials) | NIST CSF 2.0 ID.AM-03 |
| F (suppliers) | NIST CSF 2.0 GV.SC-06 |
| Tiering and routing | NIST SP 800-53 RA-3, PL-8; OWASP SAMM Threat Assessment (Application Risk Profile) |
Standards and references
- OWASP SAMM: Threat Assessment, Application Risk Profile
- OWASP Developer Guide: Risk profile
- OWASP: Application Security Verification Standard (ASVS)
- NIST: FIPS 199 Standards for Security Categorization of Federal Information and Information Systems
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Secure Software Development Lifecycle (SSDLC) Guide, OWASP SAMM Guide, Third-Party Risk Management Guide, Abuse Case Library Template.