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.  Physical security, information security, 7  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. 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  6.6  Physical Security, Information Security, Cybersecurity, and Occupational Safety and  Health  6.6.1  Safety and Security Issue Reporting  6_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  40 7. FAA Order 1370.121, in conjunction with the FAA Cybersecurity Steering Committee, applies.