Risk Sonar Security Risk Assessment (IT Security)

Timothy Hoffman's picture
What is required for a Risk Assessment?

Data Flow Diagram - NOTE THAT EVERY assessment requires the submission of a data flow diagram that contains port and protocol information.
This gets attached inside the assessment tool.  

To obtain a diagram (if you need assistance creating/updating this document) please contact the Customer Solutions Management group.
They will work with Central IT and the vendor to create a UCSF compliant diagram.  

They can be reached by calling 415 514-4100 and requesting a ticket for “design support” - the ticket should go to the group: ITS_BA_Customer_Solutions_Mgmt  

What is a "Risk Sonar" - Risk Assessment at UCSF?

Using RiskSonar is a way to measure the security of a system design that is complete in every respect. The process is called a distributed Systems Technical Risk Assessment and it includes measuring the security aspects of all computing devices involved in a system such as - phones, tablets, computers, servers, routers, switches, network connections, and other types of technologies. The goal of measuring system security is to protect the information. A risk assessment demonstrates how the system protections that are designed into the system positively affect the confidentiality, integrity, and availability of the information,  NOTE: the end to end system must be fully designed before the risk assessment is started. All of the questions inside the risk assessment are answered by assertions. This means that the person bringing in a system to UCSF must understand the system and have proceded through all design elements - including creation of the supporting documentation. is a software application that is used by UCSF as the system of record to collect and score the information about each of our systems. 

UCSF is required by a number of laws, regulations and policies to perform an assessment of risks. This activity helps UCSF meet Federal and State laws, 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
-  know the data classification, which is the measure of the sensitivity of the information being created, stored, transmitted or otherwise processed inside or outside UCSF.  

UCOP BFB IS-3 governs the data classification.

These are the minimum essential items required by UCOP policy.  (page 4 of UCOP Policy IS-3 found here).

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 BFB IS-3 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, every system requires 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 diagram showing all ports and IP addresses used. This one required item in the risk assessment is for a completed diagram to show what the system will look like when the system goes into final production so that an auditor can understand the system at a glance.
Also, there is an annual requirement to review all systems at UCSF.  For each assessment - we need a complete and comprehensive look at how the system will meet the minimum security standards and offer the necessary protections to the information. Here is an example of what the Network 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?

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) and/or technical 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 Be Expected during the Risk Assessment Process?


Step 1: Preparation; The assessor will send the UCSF Resource Owner an email to request system registration and once inside  - the answers to the Preparation Questions (30 Minute commitment) are submitted by clicking on "ANSWER."

  • Preparation questions are inside the application and the invitation to register comes to the UCSF technical contact via email from risksonar. com 

Step 2: Main Assessment; The assessor will send an email to the identified vendor contact (if vendor is involved) or to the UCSF respondent (if the system is entirely managed internally) - to answer a set of more Technical Questions. (30 min commitment)

  • Main questions are inside the application and the invitation comes to the vendor or technical contact via email from 

Step 3: Review; The application assigns weights to each response and automatically scores the responses. The assessor reviews the results. (0 min commitment)

  • The UCSF Security Team will then manually review the results in order to ensure compliance. There will be follow up via phone or email with you on the findings to identify mitigations necessary to meet UCSF Minimum Security Standards.

Step 4: Completion; The assessor will let you know that the assessment is finalized. (0 min commitment)

a. Once the assessment has been deemed as meeting the standards - the recommendation is sent for final approval

Step 5: Feedback; The assessor sends a separate assessment to obtain your experience and feedback on the process (5 min commitment)

This is a voluntary step of the security risk assessment that will help us improve our overall assessment process.


Who is the audience for the information you document during the design and risk analysis phases of your project?

Depending on the data classification (more information can be found here) and circumstances for which the documentation is reviewed 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 not common by any means however preparation for them ensures appropriate diligence and information stewardship in the event the situation does occur.

The audience may typically include any or all of the following:

University of California Entities

  • UC Office of the President
  • IT Security and Policy
  • UCSF Audit
  • Other UC Campuses

Federal and State government entities

  • Office for Civil Rights (HIPAA)
  • National Institutes of Health (NIH)
  • California Department of Public Health (CDPH)

Law Enforcement

  • Federal
  • State
  • Local
  • UC