Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Revision Date: 2023.12.13

View as PDF

Table of Contents

Table of Contents
minLevel1
maxLevel6
outlinefalse
stylenone
typelist
printablefalse

Anchor
_heading=h.gjdgxs
_heading=h.gjdgxs
I. Description

The purpose of this Reliable Method (RM) is to provide process steps Sage employees should take in reporting a suspected data incident within one of our Synapse communities and/or among users.

...

Privacy Incidents are distinct from security incidents. An actual Security Incident is a fault in the confidentiality, availability and integrity of an information system. A Privacy Incident is when protected information is used or disclosed without authorization. Not all Security Incidents result in privacy incidents, and some Privacy Incidents can occur even when technical security controls function properly. This RM provides action steps that should be taken after a Privacy Incident has been identified.

Anchor
_heading=h.1fob9te
_heading=h.1fob9te
II. Scope

This RM is applicable to all Sage Employees.

Anchor
_heading=h.3znysh7
_heading=h.3znysh7
III. Definitions & Acronyms

  • Access & Compliance Team (ACT): A subgroup of the Sage Governance Team that escalates data incidents and other violations of the Synapse Terms and Conditions of Use

  • Access Requirement (AR): A data use restriction set up by ACT that defines conditions for access to a Synapse entity.

  • Click-wrap: A type of Synapse AR that can be satisfied by a user by selecting "I accept the terms of use".

  • Data Protection Impact Assessment: A tool used to guide Sage’s evaluation of potential incidents and analysis of potential impact to users of platform tools in the event of inadvertent disclosure of personal information.

  • Incident: Suspected event that impacts the computer or data environment within Sage Bionetworks.

  • Managed AR: A type of Synapse AR that requires data access to be granted via a Data Access Committee (DAC). The Sage ACT typically serves as the DAC for Managed ARs in Synapse.

  • Personally Identifiable Information (PII): Information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual.

  • Privacy Incident: Protected information is used or disclosed without authorization.

  • Project Lead: An internal Sage team member who is a single point-of-contact actively managing a project.

  • Protected Health Information (PHI): Individually identifiable health information except as provided in paragraph (2) of this definition, that is: (i) Transmitted by electronic media; (ii) Maintained in electronic media; or (iii) Transmitted or maintained in any other form or medium. (2) Protected health information excludes individually identifiable health information: (i) In education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. 1232g; (ii) In records described at 20 U.S.C. 1232g(a)(4)(B)(iv); (iii) In employment records held by a covered entity in its role as employer; and (iv) Regarding a person who has been deceased for more than 50 years.

  • Sage Project Lead: Sage employee who helps to facilitate Synapse communities by interfacing with data contributors, curating data, or helping to manage data access or project spaces.

  • Security Incident: A fault in the confidentiality, availability, or integrity of an information system.

  • Security Incident Response Team (SIRT): Sage workforce members who are responsible for organizational response to incidents, and to prepare for incidents, assess risks, and maintain the incident response process.

  • Violation: Any behavior or action that is not compliant with theSynapse Terms and Conditions of Use,Privacy Policy, or Community Standards.

Anchor
_heading=h.2et92p0
_heading=h.2et92p0
IV. Authorities/Responsibilities

  • Sage ACT: Conduct root-cause analysis. Follow up with alerts, employee training, updating Privacy Incident Log, and resolving Jira issues.

  • Sage Employee: Report information of data Privacy Incidents to Jira Governance (SG) queue. Follow guidance of Reliable Method.

  • Data Protection Officer (DPO): Determine privacy impact of incident. Manage the resulting notification process. Ensure regulatory compliance of data privacy, including breach risk and Data Protection Impact Assessments.

Anchor
_heading=h.tyjcwt
_heading=h.tyjcwt
V. Incident Identification

  1. For the following privacy incidents, the Sage employee should create a ticket in the Governance (SG) Jira queue

  2. Examples of a Privacy Incident include:

    1. Breach of Protected Health Information (PHI), e.g., research participant’s name, date of birth, social security number or other identification number

    2. Breach of Personally Identifiable Information (PII), e.g., Synapse user’s name, identification number, email address

    3. Improper use and/or release of biomedical research data by internal or external researchers such as

      1. Failure to adhere to Conditions for Use for a given dataset

      2. Failure to comply with Synapse governance policies and procedures

      3. Failure to follow ethical principles for use of biomedical research data (e.g. Common Rule or Declaration of Helsinki)

  3. For the following violations, the Sage employee should create a ticket in the Governance (SG) Jira queue. The Synapse user may create a ticket by clicking the “Report Violation” in Synapse and filing a report or by writing to the Data Protection Officer by email

  4. Examples of a Synapse Violation include:

    1. Violating the Synapse Code of Conduct

    2. Violating the Synapse Terms and Conditions of Use

    3. Violating the Privacy Policy

  5. Examples of Remediation of a Synapse Violation:

    1. Revocation of User’s access to the Data Contributor’s project.

    2. Data Contributor determines the User's ability to reapply for data access).

    3. Revocation of Certification Quiz and re-training of use of Synapse platform.

Anchor
_heading=h.wvi0omkv0qm9
_heading=h.wvi0omkv0qm9
VI. Procedures

  1. Sage Employee will complete the following steps in any instance where they suspect or are certain that a privacy incident or violation occurred:

    1. Promptly report the suspected incident to your supervisor to evaluate if an incident has occurred.

    2. If an incident has occurred, identify the incident type (i.e., privacy or security) and refer to the Roles and Responsibilities table in the IT Confluence Incidents SOP to report the incident to appropriate Security Incident Response Team (SIRT) member for follow-up.

    3. Confirm with your supervisor immediate action steps for risk mitigation.

  2. Sage Employee will file a Jira ticket as soon as possible under theGovernance Project (SG) using the “Report Synapse Violation” Jira component.

    1. Within the Jira ticket, tag the Data Protection Officer (Christine Suver), Research Regulatory & Compliance Team Lead (Vanessa Barone), Principal Security and Compliance Manager (Brad Egloff), Governance Analyst (Kim Corrigan) and the Project Lead with as much information as you have, including but not limited to:

      1. What data is included in the breach,

        1. synIDs if the breach involves data on Synapse

        2. Whether the breach contains sensitive data (PHI/PII)

      2. The nature of the breach (e.g., data distributed through an improperly controlled Synapse project or a compromised Synapse account),

      3. How and when the breach was discovered and by whom,

      4. What steps have been taken so far, if any

      5. Comment with updates in the Jira as you gain more information

  3. Sage ACT will:

    1. Determine what steps need to be taken and by whom to secure the data AS SOON AS POSSIBLE (timeline should be defined in project-specific regulatory documents, but is typically 24-72 hours after initial knowledge of privacy incident). Reference the Incident Categories in Section VII to assist with next steps for risk mitigation. Examples of privacy risk mitigation may include:

      1. Revoking user access to data

      2. Locking down the data, i.e., making the files or entities private

      3. Notification of incident to user and/or data contributor, and advising on action steps.

      4. Request to IT that data be made private

    2. Review the data incident/suspected data breach to determine the sensitivity of the data, such as whether it included any PHI or PII, the extent of the incident/breach, and what immediate steps should be taken to limit any further incident breach of data. Incidents involving PHI/PII must be reported to the Data Protection Officer.

    3. Determine who should be alerted to the incident and what additional steps are needed. See Platforms User Data Protection Impact Assessment (Platforms DPIA) for breaches related to a Sage platform and/or tool. Any additional project-specific regulatory documents such as the privacy policy, data sharing agreement, or project-specific DPIA should also be reviewed

    4. If the data incident is related to a Synapse Project or is the result of an action taken by a Sage Employee, Sage ACT will ensure that Sage Employees complete the following steps.

      1. If the incident is related to a Synapse project:

        1. Sage ACT will revoke employee certification status

        2. Sage Employee will re-take the certification quiz

      2. If the incident is the result of an action taken by a Sage Employee:

        1. Sage Employee will complete the NIH Information Security and Management Training module

        2. Sage Employee will download their training completion certificate and email it to Sage ACT

        3. Sage ACT will attach it to the Jira issue and update the /wiki/spaces/I/pages/819953732

    5. If the incident is related to an Independent User project:

      1. Sage ACT determines the type of violation that has occurred.

      2. Determines if there has been a violation of the Data Contributor’s project Conditions for Use.

      3. If Sage ACT has access to the project, revoke User access to project.

      4. If Sage ACT does not have access to project, message Data Contributor to add ACT as Administrator to project, then revoke User access.

      5. Sage ACT creates a ticket in ACT SD and messages the Data Contributor with details of violation and actions taken. Sage ACT will communicate with the data contributor to understand their expectations with regard to restoring user access to the data. (If a Synapse Terms and Conditions of Use violation has occurred, Sage ACT will coordinate action steps with data contributor, e.g., User has to retake Certification Quiz before the user can reapply for data access)

      6. Sage ACT creates a ticket in ACT SD to message the User regarding violation, actions taken, investigation process, and next steps. Link ticket to original ticket to Data Contributor.

      7. Sage ACT creates a ticket in the Governance SG queue and links to the original ACT SD ticket to Data Contributor. The SG ticket must be created to allow the Data Protection Officer to validate resolution of the issue.

      8. Sage ACT resolves all Jira issues and update the Security Incident Log and set the validator of the Governance SG issue to the Christine Suver, Data Protection Officer

    6. Conduct a root-cause analysis to determine why the breach occurred and to prevent future risk of breach.

  4. Designated Sage ACTmember will file the breach within theSecurity Incident Log.

    1. Instructions for creating an entry in the Security Incident Log.

      1. Open link to the Security Incident Log and navigate to the menu on the left side of page

      2. Click on the “+” sign to the right of Security Incident log

      3. Add child page to entry

      4. On right side of page, ensure that “Incidents” is selected in the drop-down menu

      5. In child page, add the title and context for the incident

      6. Click “Publish”

    2. Instructions for editing an entry in the Security Incident log

      1. Open link to the Security Incident Log. On the main Confluence page, locate and click on the link to the incident in progress

      2. In the menu on the upper right side of page, click the edit button

      3. Update incident and click “Publish”

      4. To save changes without publishing, click “Close”

Anchor
_heading=h.tarsbt26kjmf
_heading=h.tarsbt26kjmf
VII. Incident Categories

  1. Click-wrap or ACT-managed Access Requirement was inadvertently removed from an entity

    1. ACT should reinstate the removed ACT-managed Access Requirement or click-wrap immediately

    2. Review the breached data type

      1. Determine whether the entity contains sensitive data by contacting the Sage Community Manager if applicable. Breaches of sensitive data are more serious in nature and should be prioritized.

      2. For Challenge data, ACT should review the Challenge Data Transfer Agreement (called Memorandum of Understanding (MOU) for older Challenges) to verify whether Challenge data is intended to be released after the Challenge concludes and whether secondary use of data is authorized.

        1. If the data was not intended to be released, loop in the data contributor and ensure that all downloaders have deleted local copies of the data. See instructions in 1.d.

    3. ACT should review the removed click-wrap or ACT-managed Access Requirement.

      1. A click-wrap only indicating acknowledgement/citation likely does not require you to loop in the data contributor

      2. A click-wrap or ACT-managed AR indicating restrictions for data use may require you to reach out to the data contributor about the breach. Review the data contract if applicable for more information.

    4. ACT should submit a Jira issue to IT and request a list of downloaders from the Synapse Administrator from the time that the AR was removed to the time that it was reinstated, and contact each of them via email.

      1. Request that all local copies of the entity be deleted

      2. Suggest re-requesting access now that the restriction has been reinstated

      3. ACT will document email responses in the Jira issue

  2. A restricted file was duplicated and uploaded publicly with no restrictions

    1. ACT should follow the steps from category 1, but ensure you contact both the duplicate creators and the duplicate downloaders

      1. Explain the issue and request that duplicate creators make any copies private

      2. ACT will contact downloaders and request deletion of local copies of data and instruct users to re-request access via the source entity

      3. You can implement a blank AR on the duplicates to prevent download. Example: “Dataset duplicates cannot be publicly downloaded. Please go to the source entity ( synxxxxxxx ) and agree to terms of use for download access. ACT is unable to accept any access requests to entity duplicates.”

Anchor
_heading=h.3dy6vkm
_heading=h.3dy6vkm
VIII. Use Cases

  • Violation of Project Conditions for Use and Synapse Terms and Conditions of Use

    • Project Type: Independent User

    • Scenario: A Registered, Certified and Validated Synapse user was approved for data access to an Independent User project. The Synapse User downloaded a file from the project. The User was seeking assistance with a data download issue and requested help troubleshooting the issue by submitting a request to act@sagebase.org and attaching the downloaded file.

    • Issue: The attachment of the file violated the Project Conditions for Use and the Synapse Terms and Conditions for Use. The User had agreed to the following: “You commit to keeping these data confidential and secure and will not redistribute data or Synapse account credentials.”

    • Identification:

      • Sage ACT identified that the file attachment contained sensitive data and was a violation of both the Project Conditions for Use and the Synapse Terms and Conditions of Use

    • Immediate triage and containment:

      • Sage ACT revoked User’s access to Project data

      • Sage ACT submitted a Jira ticket to IT requesting that the User’s Synapse Certification Quiz be revoked in response to the Synapse violation

      • Sage ACT communicated with User and Data Contributor regarding violations, immediate action steps taken, and remediation next steps

      • Sage ACT communicated with the Data Contributor regarding restoration of user’s access to the data. The Data Contributor determined that they would allow the user to re-apply for data access

      • Sage ACT communicated to the Data Contributor and User that the user had also violated the Synapse Terms and Conditions of Use and would be required to retake the Certification Quiz as part of the re-training and violation response process prior to reapplying for data access to the Independent User project.

    • Recovery and Follow-up:

      • User completed Certification Quiz and re-applied for data access

      • Data Contributor reviewed and approved data access request

      • Jira issues were resolved by Sage ACT and Security Incident Log was updated. The Jira issue was validated by the Data Protection Officer.

Anchor
_heading=h.qzenrbp5oowj
_heading=h.qzenrbp5oowj
IX. Associated Documents and Resources

Anchor
_heading=h.1t3h5sf
_heading=h.1t3h5sf
X. Revision History

Revision#, Date

Description

V1, 2023.12.1513

New version as RM.