Security Design Review

The Security Design Review (SDR) process is a collaborative discussion on the multilayer security around the application/system technical design and procedures. The Security Design Review team will review the platform, database, application, as well as the security in between each layer. The process compares the design to appropriate security standards and compliance requirements (i.e. HIPAA, FERPA, and GLBA, etc). These reviews will help uncover security vulnerabilities that can have a cascading security impact if left undiscovered.

Use the WebMethods SDR form in addtion to one of the SDRs below if WebMethods is being used to transfer data.

Use the Lite SDR form if:

It’s a managed or supported internal system or application (supported by Yale, on Yale equipment and network)… AND
Does NOT include any major architectural or application upgrade or change.
Does NOT present a substantial risk to the University or have a significant effect on the infrastructure.
Is NOT being used to receive, transmit or store any ‘three-lock’ records (data).
Is NOT registered as an above-threshold system.
Does NOT contain any of the following data fields:

Social Security Numbers (SSN)
Credit Card Numbers (CC)
Bank Account Numbers (BA)
Protected Health Information - PHI (HIPAA)
Veterans Administration data (VA)
Passport Numbers (PPN)
Animal Research (AR)
Human Subjects Research that is not ‘de-identified’ - see checklist (HSR)
Student data subject to FERPA (FERPA)
Please note that some student FERPA data does NOT fall under a 3 lock data classification and you could use the Lite form. Please consult ITS Security.

Use the Application Service Provider (ASP) SDR form if:

The systems or applications being managed and supported externally (ASP model) and there is no 3-Lock data. This ASP SDR will require additional documentation from the vendor.

A SAS70 type II report (other certifications are acceptable like SysTrust or Electronic Healthcare Network Accreditation Commission (EHNAC))
A penetration test over the vendor site.

All others please use:

Security Design Review form

SDR helpful links

For a list of the form questions that you can copy & paste into an email or other document, see SDR Questions.
Guide to completing the SDR form (PDF)
3 Lock Controls (PDF)

SDR FAQs

Who needs to do a Security Design Review (SDR)?

Currently ITS Enterprise Systems staff that are designing/implementing any new system/application critical to Yale or involving restricted/sensitive data need a Security Design Review (SDR). Some examples of restricted/sensitive that would trigger a SDR are: social security numbers, credit card numbers, protected health information (clinical care or clinical research), Veterans Administration information, FERPA information, HR or financial information. If you are uncertain as to the classification of information in an application, contact ITS Information Security.

How is a SDR performed?

A SDR review starts with a completed form. After you complete this form please request an initial SDR meeting with the Information Security Office (ISO) in an email to security@yale.edu and including the names of all persons who should take part in the review process. At the first meeting the Information Security Office Security Design Review team will go over your submitted SDR and ask for details or clarifications. After this discussion the ISO will send an email out with any additional questions, work or research that is required. Just prior to implementation schedule another meeting with the review team (e-mail: security@yale.edu) to discuss any design changes from the initial SDR and any additional issues or concerns.

Why do I need a SDR?

The point of a SDR is not to increase the application cost nor block the application from migrating into production; the SDR process will provide recommendations for building, improving, or reengineering your design to meet University policies, industry best practices, laws, and regulation requirements. A flawed design or implementation can increase the security risks and could have legal repercussions for Yale. The Yale Information Security Office understands that we cannot eliminate risks altogether, but the focus of security is to minimize Yale’s risk and potential liability to an acceptable level.