the Air Traffic Organization (ATO) Safety Management System (SMS) Manual for SRM document requirements. 

Changes to legacy systems can involve the addition of new functions or the introduction of a new combination of existing functions to the legacy system. New technologies may also have an effect on existing hazards or how they are controlled. For example, a particular function may be activated by a mechanical switch in the legacy system but enabled by software in the legacy system’s changes. If the analysis of the changes determines that there are new or newly combined functions, or if there is any impact on existing hazards or how they are controlled (or any introduction of new hazards), the standard SRM activities documented in the SMS Manual are required. 

These analyses may be facilitated by examination of the legacy system’s Concept of Operations, Functional Analysis, Shortfall Analysis, Enterprise Architecture products, and preliminary requirements in the preliminary PRD, if any exist. Most likely, detailed design and “as-built” technical baseline documentation with successive modifications are sufficient for lifecycle support, yet they may lack in early explanations of the concepts, alternatives, and requirements that the legacy system traded off years ago. Years of live operational data archives may be present, which must be valued more highly than plans, models, or future expectations of performance. For example, many years of adequate specification performance to a frozen baseline at multiple sites (actuals) must trump independent, discontinuous future estimates of failure likelihood that ignore such a strong basis for trend analysis. In all cases, the PO should hold an SSM (and consult with the ATO Chief Safety Engineer, as necessary) to determine if the program should develop an SRM document per the current AMS milestone requirements. 

A program undergoing legacy system changes needs to comply with all aspects of the AMS and SRM processes. The requirements for each legacy system change are typically very streamlined or tailored compared to the original program. For legacy system changes, the PO must conduct an SSM (consulting with the ATO Chief Safety Engineer, as necessary) to identify the SRM requirements as soon as practicable. Each legacy system change varies in its purpose and requirements, but the SRM requirements may be minimal if the legacy system change’s form, fit, and function are the same as when the program first went through the AMS process. 

## 6.6 Physical Security, Information Security, Cybersecurity, and Occupational Safety and Health 7 

Physical security, information security,  cybersecurity, and Occupational Safety and Health (OSH) (including Fire Life Safety (FLS)) issues can sometimes impact the safety of the operational NAS. When this is the case, these issues fall within the scope of the SMS. The PO must consider these issues and record them in the SRM document as well as treat, track, and monitor them as safety requirements in accordance with the processes contained in the SMS Manual. Consideration of such issues is best done by consulting representatives from each discipline (prior to convening any SRM panel) and allowing their participation in the SRM panel, as necessary. 

## 6.6.1 Safety and Security Issue Reporting 

Regardless of whether an issue falls within the scope of the SMS, the PO is responsible for reporting any potential OSH, information security, operational security, physical security, and cybersecurity issues identified by an SRM panel to the appropriate authority for possible 

