Engineering a Faster, Safer Path to Innovation Across VA OIT
The next generation of cybersecurity should not be measured only by the number of assessments completed, tools deployed, vulnerabilities identified, or reports submitted. Those activities remain necessary, but the more important measure is whether cybersecurity helps VA adopt useful technology faster, operate more reliably, and protect Veterans’ information more effectively.
VA can expand access to modern cloud, artificial intelligence, data, endpoint, and mission technologies without lowering the standard for production use. The key is to treat cybersecurity as an enterprise integration function—connecting acquisition, architecture, engineering, authorization, operations, and continuous monitoring across OIT.

A Wider Front Door, Followed by a Stronger Security Path
VA’s evolving cloud-acquisition approach can allow a provider to propose, compete, and receive a contract award without already holding FedRAMP certification. That flexibility gives VA access to newer, smaller, and more specialized companies that may offer better capabilities, lower costs, or faster implementation.
It does not mean that an award automatically permits a service to operate in production. The selected capability must still complete VA’s security assessment and Authorization to Operate process. Where FedRAMP remains applicable, the provider must also complete the appropriate FedRAMP path.
The result should be a wider front door for competition, followed by a rigorous, evidence-based path to production. An existing certification can provide reusable evidence, but it does not answer every question about how a product will be configured, integrated, accessed, monitored, and sustained within VA. Likewise, the absence of an existing certification does not prove that a product is insecure. It means the provider must demonstrate security through architecture, testing, control evidence, vulnerability management, privacy protections, and operational readiness.
Cybersecurity Must Begin With the Mission Need
Security should enter the process when an OIT mission requirement is first defined—not after a technology has been purchased or a system is nearly ready for deployment.

Early security architecture should define authorization boundaries, identities, trust relationships, data flows, access controls, encryption, logging, retention, dependencies, and integration points. Threat modeling should examine external attacks, insider misuse, privileged-access abuse, compromised third-party components, manipulated telemetry, and attempts to bypass deployment controls.
This work should produce actionable choices rather than static lists of concerns. OIT leaders need to understand design alternatives, compensating controls, implementation costs, remediation priorities, and residual risk before a decision becomes expensive or difficult to reverse.
Engineering must then turn those decisions into secure baselines, technical controls, integration specifications, automated testing, and traceable evidence. Security gates should be placed directly into development and deployment pipelines so that configuration, code, dependencies, and controls are tested continuously rather than reconstructed shortly before authorization.
New Tools Should Improve the Portfolio
Greater access to commercial technology should not create uncontrolled tool growth. VA should be able to procure new capabilities while reducing redundant products, underused licenses, incompatible data, duplicate alerts, and avoidable technical debt.

The process should begin with a real mission or cybersecurity gap, not with a vendor demonstration. OIT should first determine whether an existing product can meet the need through better configuration or integration. When a new tool is justified, its security value, lifecycle cost, implementation burden, interoperability, staffing impact, and expected outcomes should be understood before broad deployment.
Supply-chain risk must be part of the same decision. Vendor dependencies, software components, Software Bills of Materials, known vulnerabilities, update practices, incident-notification procedures, data location, third-party access, and product provenance all influence whether and how a capability should be implemented.
A representative security engineering environment can test identity controls, segmentation, encryption, logging, data flows, integration behavior, resilience, and control effectiveness before enterprise deployment. The goal is to identify problems while they are manageable and give decision-makers clear options: approve, approve with restrictions, conduct a limited pilot, require remediation, or reject.

AI Can Make Cybersecurity More Proactive
Artificial intelligence can increase OIT’s cybersecurity capacity when applied to specific, measurable operating problems.
AI can help reconcile inconsistent asset inventories, normalize telemetry, identify configuration drift, correlate alerts and threat intelligence, prioritize vulnerabilities by exploitability and mission impact, detect unusual patterns, and identify missing security evidence. AI-assisted workflows can also support initial analysis, draft risk summaries, recommend remediation actions, and reduce repetitive analyst work.

AI should not independently authorize systems, accept residual risk, or take consequential action against mission-critical infrastructure without appropriate controls. OIT must also understand the AI embedded in commercial products: what data the model uses, where it is processed, whether VA information can be retained or used to improve a commercial model, how outputs are evaluated, and how model changes could affect security.
Responsible AI governance should enable adoption rather than block it. Approved environments, clear data controls, model documentation, output testing, continuous monitoring, human review, corrective-action processes, and disclosure of material model changes allow VA to use AI with greater confidence.

Security Does Not End at Authorization
Authorization is a decision point, not the end of cybersecurity engineering.
After deployment, OIT needs continuing evidence that systems and tools remain secure, correctly configured, and operationally effective. Asset inventories must remain accurate. Security agents must remain healthy. Telemetry must be complete. Integrations must continue to work. Vulnerabilities must be prioritized and remediated. Significant changes must be evaluated for their effect on the security posture.
Measurable targets are essential. OIT should expect enterprise asset visibility and data accuracy at levels such as 97 percent or better, while also tracking coverage gaps, agent health, false positives, duplicate alerts, response performance, control effectiveness, and remediation status.
Data protection must follow VA information wherever it is created, transmitted, processed, analyzed, or stored. Sensitivity tagging, access restrictions, encryption, Data Loss Prevention controls, monitoring, and response should operate as connected capabilities. Cryptographic inventories and migration planning should also prepare systems for approved modern standards, including post-quantum requirements where applicable.

The Desired Result
The objective is not to create another review layer. It is to establish cybersecurity as the integration layer across OIT product lines, cloud environments, applications, infrastructure, endpoints, medical devices, identity systems, data platforms, security tools, and authorization activities.
Done well, this model gives VA greater access to emerging technology, stronger control over enterprise risk, faster and more defensible decisions, better tool integration, more effective use of AI, and improved resilience across the systems supporting Veterans.
Technology choice and cybersecurity assurance are not competing objectives. When security is engineered into the full OIT lifecycle, VA can adopt innovation faster while improving the protection, reliability, and operational performance of its mission-critical services.