Introduced in the mid-1980s by Dr. Barry Boehm, the Spiral model does a much better job of managing risks through one of its core attributes as a process generator. Through multiple successive iterations—starting with a firm set of requirements—the concept of operations (CONOPS) is established, requirements are developed (before Spiral development actually starts), the product is developed, tested, verified/validated, and finally released.

The Spiral methodology was originally created for software. Each iteration in this model:

• Evaluates or reevaluates what the conditions of project success mean for stakeholders
• Determines whether alternative approaches are needed to achieve project success
• Evaluates risks from the selected approach
• Gains approval from stakeholders

Spiral development offers a balance between the upfront investment in time required during waterfall development, and the speed associated with Agile developments. Programs developed using Spiral models allow an initial set of capabilities to be developed during the first Spiral, with additional capabilities being developed and fielded during subsequent Spirals.

This often requires development teams to support engineering of the next Spiral's capabilities, development of the current Spiral's capabilities, and operation of the previously fielded Spiral's software at the same time. 

Spiral software programs still adhere to many of the waterfall processes such as gate reviews. These reviews are done at least once per Spiral, and include system requirements reviews, preliminary design reviews, and critical design reviews.

As with waterfall programs, documentation plays a critical role in the development process. Requirements specifications, design documents, security plans, and test plans and procedures are all created and updated during the program. 

The Spiral approach still mandates that all high-level requirements are developed and known in advance, and reflected in a CONOPS document. However, this takes place from a development perspective—covering architecture development, implementation, and so on.

The Spiral model can facilitate improving the security design through successive iterations (each producing prototypes, and so on) until a final product is delivered:

Verification and validation also play an important role in a Spiral development effort. Just as with waterfall programs, an SRTM should be created that allows security engineers to track security requirements to completion.

A security test plan and procedures document should be created and updated each Spiral, to verify the incorporation of mandatory security requirements. Penetration tests should also be run against each successive Spiral's fielded software.