TDA-12: Input Data Validation
Mechanisms exist to check the validity of information inputs.
Renumbered: Formerly TDA-18 in SCF 2025.4.
Code reused: In SCF 2025.4 and earlier, TDA-12 was Customized Development of Critical Components. That control is now TDA-10.
Control Question: Does the organization check the validity of information inputs?
General (29)
| Framework | Mapping Values |
|---|---|
| AICPA TSC 2017:2022 (used for SOC 2) (source) | PI1.2-POF1 PI1.2-POF2 PI1.2-POF3 |
| GovRAMP | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| GovRAMP Core | AC-02 SI-03 SI-04 SI-07 |
| GovRAMP Low | AC-02 AC-03 SI-03 SI-04 SI-05 |
| GovRAMP Low+ | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| GovRAMP Moderate | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| GovRAMP High | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| IEC 62443-3-3 2013 | SR 3.5 |
| IEC 62443-4-2 2019 | CR 3.5 |
| MITRE ATT&CK 16 | T1021.002 T1021.005 T1027.010 T1036 T1036.005 T1036.008 T1048 T1048.001 T1048.002 T1048.003 T1059 T1059.001 T1059.002 T1059.003 T1059.004 T1059.005 T1059.006 T1059.007 T1059.008 T1071.004 T1080 T1090 T1090.003 T1095 T1127 T1127.002 T1129 T1176 T1187 T1190 T1197 T1204 T1204.002 T1216 T1216.001 T1218 T1218.001 T1218.002 T1218.003 T1218.004 T1218.005 T1218.008 T1218.009 T1218.010 T1218.011 T1218.012 T1218.013 T1218.014 T1218.015 T1219 T1220 T1221 T1498 T1498.001 T1498.002 T1499 T1499.001 T1499.002 T1499.003 T1499.004 T1530 T1537 T1546.002 T1546.006 T1546.008 T1546.009 T1546.010 T1547.004 T1547.006 T1548.006 T1552 T1552.005 T1553 T1553.001 T1553.003 T1553.005 T1557 T1557.001 T1557.002 T1557.003 T1564.003 T1564.006 T1564.009 T1570 T1572 T1574 T1574.001 T1574.006 T1574.007 T1574.008 T1574.009 T1574.012 T1574.013 T1574.014 T1599 T1599.001 T1602 T1602.001 T1602.002 T1609 T1622 |
| NIST 800-53 R4 | SI-10 |
| NIST 800-53 R5.2 | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| NIST 800-53B R5 (low) (source) | AC-02 AC-03 SI-03 SI-04 SI-05 |
| NIST 800-53B R5 (moderate) (source) | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| NIST 800-53B R5 (high) (source) | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| NIST 800-82 R3 | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| NIST 800-82 R3 LOW OT Overlay | AC-02 AC-03 SI-03 SI-04 SI-05 |
| NIST 800-82 R3 MODERATE OT Overlay | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| NIST 800-82 R3 HIGH OT Overlay | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| NIST 800-160 Vol2 R1 | SI-07 |
| NIST 800-161 R1 | AC-2 AC-3 AC-5 SI-3 SI-4 SI-5 SI-7 |
| NIST 800-161 R1 C-SCRM Baseline | AC-2 AC-3 SI-3 SI-4 SI-5 SI-7 |
| NIST 800-161 R1 Flow Down | AC-2 AC-3 AC-5 SI-3 SI-4 SI-5 SI-7 |
| NIST 800-161 R1 Level 1 | SI-4 SI-5 |
| NIST 800-161 R1 Level 2 | AC-2 AC-3 AC-5 SI-3 SI-4 SI-5 SI-7 |
| NIST 800-161 R1 Level 3 | AC-2 AC-3 AC-5 SI-3 SI-4 SI-5 SI-7 |
| NIST 800-172 R3 | 03.14.12E |
| NIST 800-172A R3 | DS-A.03.14.12E A.03.14.12E.ODP[01] |
| OWASP Top 10 2025 | A08:2025 |
US (12)
| Framework | Mapping Values |
|---|---|
| USA Federal CMS MARS-E 2.0 | AC-2 AC-3 AC-5 SI-3 SI-4 SI-5 SI-7 SI-10 |
| USA Federal CJIS Security Policy 6.0 | AC-2 AC-3 AC-5 SI-3 SI-4 SI-5 SI-7 SI-10 |
| USA Federal 21 CFR Part 11 2025 | 11.10(h) |
| USA Federal FFIEC ITEH 2016 | II.C.17 |
| USA Federal FedRAMP R5 (low) | AC-02 AC-03 SI-03 SI-04 SI-05 |
| USA Federal FedRAMP R5 (moderate) | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| USA Federal FedRAMP R5 (high) | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
| USA Federal FedRAMP R5 (LI-SaaS) | AC-02 AC-03 SI-03 SI-04 SI-05 |
| USA Federal IRS 1075 2021 | AC-2 AC-3 AC-5 SI-3 SI-4 SI-5 SI-7 SI-10 |
| USA Texas DIR SCSC 2.2 2025 | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-10 |
| USA Texas TX-RAMP Level 1 | AC-02 AC-03 SI-03 SI-04 SI-05 |
| USA Texas TX-RAMP Level 2 | AC-02 AC-03 AC-05 SI-03 SI-04 SI-05 SI-07 SI-10 |
EMEA (1)
| Framework | Mapping Values |
|---|---|
| EMEA Saudi Arabia SACS-002 2022 | VII.B.TPC-60 |
APAC (6)
| Framework | Mapping Values |
|---|---|
| APAC Australia ISM June 2026 | ISM-2059 |
| APAC India RBI Digital Payments 2021 | 66.0 |
| APAC India RBI PA 2025 | IV.13.g |
| APAC Japan ISMAP | 14.2.5.9 |
| APAC Malaysia RMiT 2025 | A5-E1(c) |
| APAC Singapore CCOP CII 2026 | 10.3.4 |
Capability Maturity Model
Level 0 — Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 — Performed Informally
Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Technology development & acquisition-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160).
Level 2 — Planned & Tracked
Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments.
Level 3 — Well Defined
Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to check the validity of information inputs.
Level 4 — Quantitatively Controlled
Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.
Level 5 — Continuously Improving
Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies.
Assessment Objectives
- TDA-12_A01 information inputs to the system requiring validity checks are defined.
- TDA-12_A02 the validity of the organization-defined information inputs is checked.
- TDA-12_A03 approved authorizations for logical access to information and system resources are enforced in accordance with applicable access control policies.
Evidence Requirements
- E-WEB-04 Web Application Input Validation & Output Encoding
-
Documented evidence of web application input validation, sanitization and output encoding controls (e.g., test results, framework configuration).
Website Security
Technology Recommendations
Micro/Small
- Input validation in developed applications (OWASP Input Validation Cheat Sheet)
Small
- Secure coding standard requiring input validation
- Web framework validation features
Medium
- Input validation requirements in SSDP (allow-list validation, parameterized queries)
- SAST checks for injection
- Web Application Firewall (WAF)
Large
- Input validation standards (OWASP ASVS) enforced through SAST/DAST
- WAF/API gateway validation
- Security unit tests
Enterprise
- Enterprise secure coding standards with automated input validation testing (SAST, DAST, IAST, fuzzing)
- WAF and API security platforms
- Runtime application self-protection