System Registration and Protection Procedures


The procedures described in this section support the Registration and Protection of Systems Policy. Work instructions for these procedures will be documented and maintained by Certified IT Groups. Note that additional procedures and guidance for Servers, Medical Devices, or other specialized equipment may be required.

Please see the main CUIMC Information Security Procedures page for an overview, effective date and definitions.

A. System Operation

All Systems, and their underlying components (such as Servers), that process, transmit and/or store EPHI must be explicitly managed by a Certified IT Group. To be explicitly managed, the System must meet the following criteria, in addition to the criteria referenced in the Registration and Protection of Systems Policy:

B. System Registration Procedures

All Systems within CUIMC must be registered with the CUIMC Information Security Office in accordance with the following procedure:

  1. After determination the System will be acquired, the System Owner, or IT Custodian, will access RSAM (https://rsam.cumc.columbia.edu) and fill out the System Registration object.
    1. Work instructions for this procedure will be documented by the CUIMC Information Security Office, and can be found on the RSAM System Registration Walkthrough website.
  2. The business purpose and functions of the System must be clearly identified. This will include the following attributes:
    1. The number of users of the System;
    2. The number of records the System holds; and
    3. The date the System went, or will go, into production.
  3. Other demographic information must be captured, including:
    1. System Owner;
    2. IT Custodian(s);
    3. Other stakeholders;
    4. Classification of Data stored or processed by the System (Sensitive, Confidential, Internal or Public);
    5. Location of the Servers’ Data Center;
    6. The types of services the System provides (such as Application, Database, Email, etc;)
    7. Flow of Data (especially Sensitive Data) into and out of the System;
    8. Types, amounts and identifiable characteristics, of Data processed, transmitted and/or stored;
    9. Users of the System;
    10. Exposure of the System to the Internet; and
    11. Maximum allowable permissible downtime.
  4. All servers supporting the System must be inventoried and documented. This information should be entered into RSAM, with the following attributes:
    1. IP Address;
    2. Hostname;
    3. Operating System; and
    4. Server’s purpose. 

C. System Risk Analysis

Systems that have been registered with the CUIMC Information Security Office will be evaluated based on the risk they introduce into CUIMC. This is done through a number of steps and via the following general procedures:

  1. Newly registered Systems will undergo an initial “inherent risk” evaluation by the CUIMC Information Security Office to determine the criticality of the System and the amount of risk it introduces into CUIMC. This evaluation will take into account:
    1. The classification of Data stored or processed on the System;
    2. The number of uniquely identifiable records stored on the System;
    3. The number of Users of the System; and
    4. The exposure of the System to the Internet.
  2. A Controls Based Assessment (CSA) will be provided to the System Owner, which will contain a list of controls based on the nature of the System. The System Owner is responsible for evaluating the configuration of the System against the CSA and providing the results to the CUIMC Information Security Office.
  3. The CUIMC Information Security Office will review the results of the CSA and identify any gaps that might exist. Gaps that have been identified will be classified as vulnerabilities.
  4. The CUIMC Information Security Office will conduct a technical vulnerability scan against all Servers comprising the System. The results of the vulnerability scan will be added to the list of identified vulnerabilities.
  5. The CUIMC Information Security Office will evaluate the threats associated with any technical vulnerabilities and/or any vulnerabilities discovered during the CSA analysis. This threat to vulnerability mapping will result in an evaluation and rating of the gaps with a risk score.
  6. All risks are described by three descriptive components, namely:
    1. Issue – the reason why the determined gap is a problem
    2. Risk – a statement about the risk the gap introduces to the organization and its impacts
    3. Solution – a recommended resolution to remove or mitigate the risk
  7. An overall risk score of the System will be recorded based on the highest level of any individual component risk. E.g., if a System is deemed to contain 5 risks comprised of 4 low risks and 1 high risk, then the overall risk of the System will be “High”.
  8. A final report will be compiled by the CUIMC Information Security Office, comprised of an executive summary, detailed risk findings and technical vulnerability results, and submitted to the Executive Manager of the department or business unit. If the System contains no risks it will be given a score of “Pass” and will be immediately granted “Certified” status. 

D. System Remediation

Any System that is found to have risks must undergo a formal Corrective Action Plan and the development of a Plan of Action and Milestones. The following procedures will be followed:

  1. The System Owner, upon receiving the risk analysis report, will evaluate the risks discovered.
  2. Within 30 days, the System Owner will respond to the risks identified and either (a) agree with the findings and submit the Corrective Action Plan for remediation of each individual risk, or (b) contest the risk finding.
    1. Should the System Owner contest the risk, the System Owner and the CUIMC Information Security Office will review it. If the CUIMC Information Security Office agrees with the contestation, the risk will be removed. If it does not agree, then mediation will take place. Mediation will ensure that both parties come to agreement. If necessary, the risk discussion will be escalated to Executive Management for final mediation.
  3. If the System is given a Critical or High risk score, an emergency risk plan will be developed by the System Owner to execute remediation of the Critical or High risks within 7 days of report issuance. The focus of the plan is to remediate the urgent risks in a timely manner so they are not exploited.
  4. After the remediation plan has been submitted to the CUIMC Information Security Office and approved by Security Managers, the System Owner will have 90 days to execute the plan.
  5. While the System is under remediation, System Owners will regularly report to the Security Managers the status of the remediation. In addition, Security Managers will periodically check the status of the remediation with the System Owner. 

E. System Certification

Upon attestation from the System Owner that all risks have been mitigated, the CUIMC Information Security Office will initiate a final check to provide the appropriate level of assurance that the risks have been properly mitigated. The following procedure will be followed:
  1. Security Managers will review the System’s risks and the remediation plan.
  2. Security Managers will evaluate the controls implemented by the System Owner and test that the controls appropriately mitigate the risk. System Owners will be required to provide evidence of all controls implemented to mitigate the risks.
  3. If the controls are deemed adequate and all risks have been mitigated to an acceptable level of tolerance, Security Managers will issue a Certification Report to the System Owner and his/her Executive Managers.
  4. The System will be updated in the RSAM list of CUIMC Certified Systems.
  5. The System will be scheduled for re-certification at a later date, based upon the inherent risk of the System. The higher the inherent risk of the System the more frequent the risk analysis will be conducted. 

F. New System Governance Process

All new Systems that will process, transmit and/or store EPHI must first be approved for use through an IT Steering Committee governance process. System Owners will submit their requests to the IT Steering Committee, which in turn will confirm that the System is filling a particular business need (clinical, research or administrative) and that the proper party to develop, implement and maintain the System has been identified. The process is as follows:

  1. The System Owner, IT Custodian or User will submit a Request for Approval to Implement New System email to the CUIMC CIO. The email will contain, at a minimum, the following information:
    1. Business need the System will fulfill;
    2. Evaluation of skills and capabilities needed to run the System;
    3. Priority of the request; and
    4. Constituents and Users who will use and/or be impacted by the System.
  2. The email will be forwarded to the IT Steering Committee for review.
  3. The IT Steering Committee will evaluate the request, using the following criteria:
    1. If the request has a legitimate business need that is not currently available from an existing System;
    2. If the proposed System Owner’s Certified IT Group has the appropriate skills and capabilities to implement, manage and monitor the System; and
    3. If the business need is required by more than the individual department or business unit, whether the System should be hosted locally within the Certified IT Group or centrally by CUIMC IT.

After all evaluations have been conducted, the IT Steering Committee will provide a final approval or rejection.

G. Data Backup

For all Systems containing EPHI, the System Owner must comply with Section III(C) of the Business Continuity and Disaster Recovery Policy relating to Data Backup Plans. For such Systems, the Data Backup Plan should address whether a backup of EPHI is needed before any movements of the System (e.g., to a new location).