Introduction
Applications and systems that handle protected data are required to meet the campus Minimum Security Standard for Electronic Information policy (MSSEI). The MSSEI Self Assessment Plan (SAP) is a tool for describing the controls in place to meet those requirements. A completed MSSEI SAP for UC P4 classified systems is required before the Information Security Office (ISO) can assess compliance with campus security policies.
The following is a step-by-step guide for completing the MSSEI SAP, with instructions for what information needs to be provided in each section. The self assessment plan is meant to be a snapshot in time of implemented security controls, and should be updated after any significant changes are made.
The self assessment plan is NOT meant to include information that can directly lead to the compromise of protected data, such as account credentials. A completed SAP should be considered classified as UC P3 data and shared with collaborators on a need-to-know basis.
MSSEI SAP Templates
Google document templates are available to help with the documentation effort for both UC P4 and UC P2/P3 applications. Copy the template to a shared departmental drive, with appropriate account access permissions.
UC P4 SAP Template UC P2/P3 SAP Template*
* Note that self-assessment plans for UC P2/P3 systems are strongly recommended, although they are not required to be submitted to ISO.
Who Should Complete the MSSEI SAP?
Other Compliance Responsibilities:
Please be aware that this assessment only addresses information security requirements and risks. A Privacy or Accessibility consultation may also be needed if your use case has privacy or accessibility implications. Some examples include:
- Privacy:
- Information about European residents is involved;
- If there are questions about the applicability of privacy-related laws or regulations, including data de-identification, data breach notification laws, HIPAA, FERPA, GDPR, and the California Consumer Privacy Act (CCPA);
- A Supplier is passing information classified at Protection Level P3 or higher to other third parties.
- Please contact privacyoffice@berkeley.edu
- Accessibility:
- Applications, tools, or products intended for student, departmental, or campuswide use
- Please contact webaccess@berkeley.edu. If you need a web accessibility review of a website or web-based product, please also fill out a “Request a Clinic” form
Step 1: Provide a Detailed Description of the Application or System
In the title section of the MSSEI SAP template is a table for entering basic information, such as the Application or System Name, Data Classification, Resource Proprietor, Point of Contact, and Department or Unit Name.
Refer to the campus Data Classification Standard and guideline for details about how to classify campus data, including examples for each data class. If unsure about the correct classification, contact ISO at policy@berkeley.edu for additional guidance.
The Revision History section is provided for tracking major changes and annual reviews of the self assessment plan.

1. Application / System Overview
Examples: | |
Describe the purpose of the application and how it is being used. | “This is a web-based application used for HR on-boarding purposes.” |
Include a list of the types of protected data involved. | Social Security numbers, human-subject research data, etc. |
Note any 3rd-party applications or service providers. | Oracle PeopleSoft platform; the application is a hosted SaaS service or uses AWS infrastructure |
Note any laws or regulations that apply to the application data, or any governing research data use agreements. | HIPAA, GDPR, FERPA, etc. |
2. Target Audience
Examples: | |
Include a description of the application users. | “Accounts Payable staff in the Finance office who will be administering vendor payments.” |
Also include a description of the people who may be affected by the system. | “The application contains approximately 7000 student financial aid records.” |
3. Architecture Model
Especially important to the description of the system are Section 3 - Architecture Model and Section 4 - Data Flow Description
For the Architecture Model:Examples: | |
Include a detailed diagram* that demonstrates how various parts of the system interact with one and other. | Web/app servers, database systems, storage devices, backup systems, admin devices, end-user workstations, etc. |
The diagram should include a high-level illustration of the networks involved. | Public vs. private |
Note on the diagram any devices or systems where the protected data is stored or processed. | Databases, storage devices, etc. |
Label the data-flow lines with the network protocols for transferring data and communicating between the devices. | HTTPS, SFTP, SSH, RDP, IPSec, etc. |
* Using a CAD diagramming tool, such as Visio, to create the diagram is encouraged, but a photo of a carefully drawn diagram on a whiteboard, or using pen and paper, is equally acceptable.
4. Data Flow Description
Examples: | |
Describe the inter-connectivity between various devices illustrated in the Architecture Model, including details about how protected data is being stored or processed. | “User end-points connect via HTTPS to the application server, which communicates with a backend database system where data is stored and processed.” |
Include a brief description of how each of the components of the architecture are being secured. | “The database server is hosted on a private subnet with firewall permissions to only allow access from the application server on a separate DMZ subnet.” |
5. Support & Development Staff
In Section 5, Support & Development Staff:
-
List any staff members who have elevated privileges* in the application or its underlying devices
-
Include a description of their responsibilities and email contact information
* Elevated privileges may mean administrator permissions to make changes to the application configuration, or bulk access to protected data, etc.
6. Resources
Section 6, Resources, is intended for referencing system security documentation.* The campus security policies are listed, but this section can also reference other documents or resources that impact security controls, such as departmental policies.
* These references should not include any technical documentation that could be exploited by an attacker.
Step 2. Describe How MSSEI Requirements Are Being Met

Before attempting to complete this section, read the policy and guidelines for each requirement first.* The guidelines provide detailed recommendations about how to meet control requirements, including resources for campus services to help support MSSEI compliance efforts.
Instructions are provided for each MSSEI requirement. Include as much detail as seems relevant, so that others reading the SAP will readily understand.
* There is a link to the guidelines for each MSSEI requirement in Section 7.
Covered Devices
The MSSEI policy defines three Device/Use Categories that are covered by the requirements:
Each covered device has its own subset of MSSEI requirements based upon the protection level classification of the application or system. To see which requirements apply for each device category, refer to the MSSEIBaseline Data Protection Profile Summary table.
Where applicable for each of the requirements in Section 7, space is provided to enter a description of the controls that apply for covered Institutional and Privileged Access Devices.
* While MSSEI also applies to Individual Devices, documentation of compliance for these devices is not required for the MSSEI SAP. MSSEI requirement 15.4 Data access agreements specifies that an agreement is established with end users of the application to inform them of MSSEI Individual Device requirements. The data access agreement should make clear that by agreeing to use the application or system, end users are also agreeing to meet MSSEI Individual Device requirements.
Tracking MSSEI SAP Progress
For each requirement in Section 7, the "Progress" field in the right-hand column is intended for tracking the implementation status of the security controls (e.g., "Not started", "In Progress", or "Fully Implemented").
Not Started | Security controls are currently in the planning phase, none of the security control specifications have been put into place to meet the MSSEI requirement. |
In Progress* | Planning is completed and some controls have been put into place, but not fully completed. |
Fully Implemented | All of the specifications for the security controls have been completed. |
* Requirements that are in the "In Progress" stage should include a timeline to complete the implementation of all control specifications.
MSSEI SAP Inventory Appendices
The MSSEI SAP hardware and software inventory appendices (A & B) are provided for tracking the key application system devices and installed software (per MSSEI requirements 1.2 Covered system inventory & 2.1 Managed software inventory). Only Institutional and Privileged Access devices are required to be listed in the inventory appendices (Individual Devices are optional).
Alternatively, these inventories can be maintained in separate files and referenced in the MSSEI SAP.
Step 3. Submit the MSSEI SAP to ISO
Once the self assessment is completed, it can be submitted to ISO via the MSSEI SAP submission form (form requires CalNet login). The submission will be tracked via the ISO ticketing system, where a Security Analyst will be assigned to the assessment.
Before completing the submission form, the MSSEI SAP Google Doc must be shared with the members of ISO staff for collaboration purposes.
-
Share the completed plan with the “mssei-sap@lists.berkeley.edu” Google Group
-
Assign “Edit” permissions to allow ISO Security Analysts to provide comments and suggested edits to the document
To get an overview of the MSSEI assessment process, refer to the Details of the MSSEI Assessment Service page. If you have any questions about MSSEI assessments, you may create a ServiceNow ticket by emailing security-assessments@berkeley.edu.