RiskSonar - IT Security Risk Assessment

What is a "RiskSonar" risk assessment at UCSF?

RiskSonar is a web-based software tool used as the UCSF system of record to collect information about each of our information systems and score their security compliance.  The process is called a distributed systems technical risk assessment and measures the security aspects of all computing devices associated with the system, including servers, desktop computers/laptops, phones, tablets, routers, switches, network connections, and other technologies. The goal of measuring system security is to protect the information.  A risk assessment demonstrates how the protections built into the system design positively support the confidentiality, integrity, and availability of its data.  Note that the information system must be fully designed before the risk assessment can be started. All of the questions inside the risk assessment are answered by assertions, meaning that the UCSF system owner must understand the system and have completed all design elements, including creation of the supporting documentation.  

UCSF is required by a number of laws, regulations and policies to assess the risk of information systems that create, store, process, or transmit UCSF data. This activity helps UCSF meet Federal and State laws and regulations and University policies.

To perform a risk assessment - the system owner (the person who purchases or leases the system on behalf of UCSF) or their technical delegate must:
-  identify the name of the system, 
-  have a full system asset inventory (list of all equipment), and
-  identify the data classification, which determines the sensitivity of the information being created, stored, transmitted or otherwise processed inside or outside UCSF. Please see the UCSF Data Classification Standard.

Examples of a system that would need a Risk Assessment would be a new or changed email system, a research application, or a clinical care solution.

It is important to note that it is essential that risk assessment be performed on systems that handle UCSF information outside of UCSF. 

Do You Need a Distributed Systems Security Risk Assessment?

UCOP Policy BFB-IS-3 (Electronic Information Security) identifies that security risk assessments must be conducted on all systems, applications, and vendors when they are initially introduced into the UCSF infrastructure and at times when making significant changes such as a new server or new operating system or other substantive change. Additionally, systems may require an annual re-assessment. If you are introducing a new or modified system, please ensure that the system is in final design state or as close as possible with a data flow diagram that shows all ports, protocols, and IP addresses used.  Here is an example of what the data flow diagram should look like to show all data flows, ports, protocols and whether the information is inside or outside UCSF:  Fileexample_data_flow_diagram.pptx

Have you prepared for a System/Technical Risk Assessment?


  • Have you completed the UCSF minimum security standards checklist?​ 
  • Do you have a completed data flow diagram? This is a document showing the data flow of the system from every asset and endpoint both internal and external showing the exact ports and protocols that are to be used (ie. port 443) to protect the data in transit. If you need assistance preparing the data flow diagram, please work with the Customer Solutions Management group by submitting an IT Consultation Request at 
  • Do you have all management roles of the system identified - as in who "owns" the system, who will manage accounts, who will perform patching, etc.?
  • Have the security procedures you will use to manage the system been documented?
  • Have you worked with UCSF IT to complete a Business Impact Analysis (BIA) for the system? If not, you must initiate a BIA by contacting Bernie Conlu ([email protected]), though this can be done in parallel with the risk assessment. Please see for more information.

When systems are implemented there are many decisions, assumptions and operational plans made. Reviewing these systems for security risks requires documentation of these decisions, assumptions and plans so that the aggregate product of the system can be reviewed to ensure adequate protections are in place. This assessment does not require additional documentation because all of the documentation should be present before the assessment is initiated. 

UCSF recommended controls may be administrative safeguards (non-technical), technical controls, or physical controls which result in a reduction in risk to the data. For a complete list of recommended security controls please see the ITS Check List Template that is also used by our Project Management Office for collecting background information prior to entering the security risk assessment. It is found here  Fileits-check-list-template-v1.docx

As stated in the HIPAA guidance on risk analysis there is no one-size-fits-all blueprint for compliance and documentation. This is because there are many different types of distributed systems and operating systems, database software, application software, programming languages, etc. which make up these systems. However to support the UCSF community we have created general recommendations for the types of information that is created for projects. Leveraging this information to create a complete view of the pertinent details of the system will support the review and ensure timely project implementation.


How To Request a Security Risk Assessment:


Once the system is in final design, and there is a data flow diagram that shows what ports are used, and the resource owner and system name are known - then
please use the following link to submit a request for system risk assessment:


What should you expect during the risk assessment process?


Step 1: Preparation:

The assessor will send the UCSF system owner an email outlining the assessment process and requirements. will then send the UCSF technical contact an invitation to register with the RiskSonar tool and to complete the preparation questions (30 minute customer time commitment).


Step 2: Main Assessment:

The assessor will send an email to the technical contact identified in the preparation questions (this may be a vendor contact or internal UCSF contact) to notify them that they will need to answer the more technical main assessment questions. will then send the technical contact an invitation to register with the RiskSonar tool and to complete the main assessment questions (30 minute customer/vendor time commitment).


Step 3: Assessment Review:

The RiskSonar tool assigns weights to each assessment response and automatically calculates a security compliance score.  The assessor will then confirm the results by manually reviewing the assessment responses and the data flow diagram to assure UCSF security compliance requirements are addressed (0 min customer commitment).  Depending on the results, the assessor may need to discuss findings or required remediations with the UCSF system owner (customer commitment depends on findings).  If the system meets security compliance requirements, the assessor will request final approval from IT Security management.


Step 4: Completion:

The assessor will email the system owner with notification that the assessment is complete and whether final approval was granted. (0 min customer commitment)


Who is the audience for the information documented by the risk assessment process?

Depending on the data classification and use case, the audience will vary.  The information gathered and documented should be organized and formatted in such a way that someone who has a technical background can understand the various components of a system, purpose, data flows/life-cycle, the security controls put in place and the management controls for the system.  In addition to the primary purpose of risk assessment review, the project documentation may be referred to by a wide ranging audience for tasks such as contractual review, grant review, incident response, board review, 3rd party review and other security attestation activities. Some of these circumstances are uncommon but preparation for them supports appropriate diligence and information stewardship in the event a breach or other incident occurs.  The audience may typically include any or all of the following: University of California entities (e.g., Office of the President, UCSF IT Security, UCSF Audit & Advisory Services, other UC campuses or medical centers), federal and state government entities (e.g., HHS Office for Civil Rights (OCR), National Institutes of Health (NIH), California Department of Public Health (CDPH)), and federal, state, local, and/or UC law enforcement.


Migration Status