mitigation. Such issues must also be recorded in the SRM document. The appropriate authority for most security issues is System Operations Security. OSH issues (including FLS) should be reported to the appropriate Service Area’s OSH/FLS professional or to Environmental and OSH Services headquarters. 

## 6.7 COTS Products 

Using a COTS product, even if it has very high reliability, does not imply that the product is safe when it interacts with other system components. Problems could be exacerbated by software because software usually controls many, if not all, of the interactions between system components. Techniques for dealing with COTS by simply equating software reliability or correctness (consistency with specifications) with safety may not prevent system accidents. In many cases, using COTS components in safety-critical systems with acceptable risk may simply be infeasible. In these cases, it is safer and less expensive to provide special-purpose software; using COTS amounts to false economy that costs more in the end. 

There are, however, situations in which COTS components can be assured to have adequate system safety. In these cases, either the system design must allow protection against any possible hazardous software behavior or a complete “black box” behavior specification must be provided by the producer of that component in order to perform a hazard analysis. 

## 6.8 Safety Performance Targets and Monitoring Plans 

All safety requirements must be verified and validated as the system is being developed prior to system implementation. In a typical acquisition program, the PO must accomplish this by applying development assurance methods and conducting design audits, developmental and operational tests and evaluations, and/or performance checks. 

However, this verification and validation of safety requirements does not eliminate the need for monitoring the safety performance of the fielded system. The PO must establish safety performance targets and begin development of the Safety Requirements Verification Table for all hazards that were identified in the PHA and develop an operational monitoring plan to track these performance targets. The duration of the monitoring activities depends on the complexity of the system being deployed, the sites at which the system will be deployed, and the nature of the established performance targets. The monitoring itself must be conducted by the risk acceptor or his/her designee. 

The PO must also recognize that: 

• The SSAR may identify workarounds to safety requirements that were not implemented prior to initial deployment, despite the In-Service Decision Authority granting approval to deploy. 

• Additional safety requirements may be developed post–Initial Operational Capability as a result of an Operational Suitability Demonstrations, Independent Operational Assessments, or Post-Implementation Reviews. 

If either of these conditions apply, the PO may need to develop additional or modified post-deployment monitoring plans as part of the SRM effort. 

Refer to the SMS Manual or contact the AJI SCL for more information on safety performance targets and monitoring plans. 

