Verification is the process that evaluates the implemented product or system to ensure it matches the intended design. Frequently, this process is also accompanied by validation, a process that checks that the system in question meets the needs of one or more stakeholders.

Depending on the type of system being developed, there may be many different test events. For example, some types of products may have to undergo extensive environmental testing to ensure the product can operate in harsh conditions (such as space, or the desert).

Some security products may have to undergo independent lab testing such as Common Criteria (CC) validation or Federal Information Processing Standards (FIPS) 140-2 validation for cryptographic modules. 

Security verification and validation should be based on tests documented within a security test plan and procedures document, and the security requirements should be defined and tracked in the SRTM. Sufficient testing needs to be conducted, both positive and negative, to verify that functional security requirements have been satisfied.

Discrepancy Reports (DRs) should be created whenever issues are identified; those DRs should be tracked to closure by development teams as the system is updated and new releases are made available. Tracking of DRs can be performed with a variety of tracking tools, from formal configuration management tools such as DOORS to Agile-based tools such as Jira in the Atlassian suite.

Given the holistic and dynamic nature of security threats and the emergence of new risks, a classic waterfall design approach for implementing security is clearly insufficient. New attacks and countermeasures emerge at such a feverish pace today that much more responsive methods are generally needed.

That said, if your device or system is a completely closed system—clearly the antithesis of the IoT—then some facets of waterfall security engineering may suffice.