{"text_format":"1","workbook":"xlsx","n_sheets":7,"sheets":["Version Ctrl","Site Profile","Control Analysis","Dashboard","Control Breakdown","Summary","Data"],"not_rendered":{"charts":3,"images":0,"macros":1,"external_links":0,"defined_names":10,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"Version Ctrl","index":0,"n_rows":12,"n_cols":8,"rows_kept":12,"cut":false,"hidden":true,"merged":[[0,0,0,8],[10,7,10,8],[11,7,11,8],[1,7,1,8],[2,7,2,8],[3,7,3,8],[4,7,4,8],[5,7,5,8],[6,7,6,8],[7,7,7,8],[8,7,8,8],[9,7,9,8],[9,2,9,6],[10,2,10,6],[11,2,11,6],[1,2,1,6],[7,2,7,6],[8,2,8,6],[2,2,2,6],[3,2,3,6],[4,2,4,6],[5,2,5,6],[6,2,6,6]]}
["EHR Security Policy Assessment Template Change Log"]
["Version Number","Date","Change Details",null,null,null,null,"Changed By"]
[1,"March 19th 2015","Initial draft created for CSC review",null,null,null,null,"Mark Carter"]
[1.01,"April 9th 2015","Updated the tool to include the \"Program Office\" requirements and Identity Provider Standard requirements. Version reviewed at the CSC on April 17th 2015",null,null,null,null,"Mark Carter"]
[1.02,"April 21st 2015","Updated the tool based on feedback from the April 17th 2015 CSC meeting. Changes include:\n- Created defined terms for each role within the site profile tab\n- Removed unnecessary questions from the site profile tab.\n- Removed high level Information Security Policy requirements where they referenced the lower level EHR security policies\n- Reversed highlighting on must vs. should requirements",null,null,null,null,"Mark Carter"]
[1.03,"May 5th 2015","Adjusted the definition of \"Viewer\" to exclude organizations that integrate or relocate data from the EHR Solution into their local systems.  Approved by all CSC members May 5th 2015",null,null,null,null,"Mark Carter"]
[1.04,"July 27th 2015","Updated the Control Analysis tab to align the Federation Identity provider standard from v1.2 to v1.3. Aligned completion instructions in the Control Analysis tab.",null,null,null,null,"Mark Carter"]
[1.05,"Feb 22nd 2016","Updates to align with December 2015 changes to the policies which changed governance roles of the Privacy and Security Committee, Strategy Committee, Steering Committee and Connecting Security Committee",null,null,null,null,"Mark Carter"]
[1.06,"Nov 23rd 2016","Updated the Federation IDP Standard 5.2 to reduce authentication log retention requirements to 2 years (60 days online and 24 months archive), also changed 4.3.7 to permit up to 1 year for a password expiration where site is compliant with supporting password controls",null,null,null,null,"Mark Carter"]
[1.07,"Oct 2nd 2017","Aligned document with the 2017 EHR Security Policy refresh",null,null,null,null,"Ravi Addepalli"]
[1.1000000000000001,"June 22nd 2018","Updated standard to include Patient access to the EHR and NIST password recommendations (NIST 800-63B).",null,null,null,null,"John Limarzi"]
[1.2,"January 24,2020","Cleaned up Formatting from edits made in Octoner 2019",null,null,null,null,"Paul Cnudde/Ana Fukushima"]

{"sheet":"Site Profile","index":1,"n_rows":22,"n_cols":2,"rows_kept":22,"cut":false,"hidden":false,"merged":[[0,0,0,3],[1,0,1,3],[2,0,2,3],[12,1,12,3],[5,0,5,3],[10,1,10,3],[17,0,18,3],[21,1,21,3],[19,1,19,3],[20,1,20,3],[3,1,3,3],[4,1,4,3],[16,0,16,3],[13,1,13,3],[14,1,14,3],[15,1,15,3],[6,1,8,3],[6,0,8,0]]}
[{"$f":"CONCATENATE(\"[The EHR Solution] Information Security Assessment Version 1.0 for \",B4)","v":"[The EHR Solution] Information Security Assessment Version 1.0 for "}]
["Instructions:"]
["1. Please fill out the HIC Name and Contact Person fields below. \n2. On the \"Control Analysis\" tab, please select the relevant roles your organization is undertaking as part of the solution. The definitions are found below, if you do not know the roles your organization is undertaking, please consult with your Ontario Health Implementation and Adoption Lead or review the relevant legal agreements your site is signing.\n3. At the end of this exercise after discussions with Ontario Health, your site Executive Sponsor must review this document and complete the organization attestation information below."]
["HIC Name:"]
["Contact for Assessment:"]
["Scope"]
["Source Policy (Standards)","All standards apply to [the EHR Solution] and all [the EHR Solution] Services, including all Patient Portals/Applications."]
[]
[]
["Definitions"]
["[The EHR Solution]","\n[The EHR Solution]: [The EHR Solution] and supporting systems designed to store and make available specified electronic PHI from the electronic health information systems of HICs.\n[The EHR Solution] includes Patient Portals/Applications (HIC or non-HIC affiliated) that facilitate Patient access to the EHR. These applications may be:\n• Provider-Gated (Provider facilitates communication with Patient)\n• Direct-to-Patients (Patient has direct access to EHR)\n• Patient-Gated (Patient delegates access to a Substitute Decision Maker/additional delegates (i.e. family member, physician, etc.)\n\n[The EHR Solution] Program: Also known as the Program Office consists of Agents and Electronic Service Providers who support [the EHR Solution] including privacy and security-related activities, initiatives and processes\n"]
["Role Definitions"]
["Data Contributor","An organization that leverages technology and related processes to provide data to the Clinical Data Repository. Alternatively, the organization's systems may be queried to provide data to a Clinical Viewer. Typically these systems are the Information System (e.g. Hospital Information System, Laboratory Information System, Clinical Information System, HL7 Interface Engine, etc.) that directly connects to [the EHR Solution] to provide clinical data.\n\nWithin the context of Ontario Health solutions, these organizations would sign the EHR Contributor Agreement."]
["Identity Provider","An organization that leverages technology and related supporting services, policies, processes, and procedures that are used to create, maintain, secure, validate, assert and manage electronic identities to [the EHR Solution].\n\nWithin the context of Ontario Health solutions, these organizations sign the eHealth Ontario Identity Provider Agreement."]
["Viewer","An organization that views data from [the EHR Solution] in accordance with the authorized permitted purposes. The organization leverages ONE ID credentials or credentials issued by an Identity Provider (e.g., a partner hospital organization, [the EHR Solution] provider, etc.) to access the solution in a read-only capacity. Viewer organizations may store some PHI locally on an ad-hoc basis but do not integrate data locally or relocate data from [the EHR Solution] to their local solution (e.g. EMR). \n\nWithin the context of Ontario Health solutions, these organizations sign the EHR Practice Agreement or EHR Access Services Schedule."]
["[The EHR Solution] Program Office / Service Provider","An organization(s) that represents, runs or supports [the EHR Solution] and supporting systems designed to store and make available specified electronic PHI from the electronic health information systems of HICs. \n\nWithin the context of Ontario Health solutions, these organizations may sign a service provider contract with Ontario Health. "]
["Organization Attestation"]
["You declare that this completed security readiness assessment accurately represents the current state of controls and operations within your organization in accordance with the EHR Security Policies."]
[]
["Executive Sponsor Name"]
["Executive Sponsor Title"]
["Date"]

{"sheet":"Control Analysis","index":2,"n_rows":726,"n_cols":14,"rows_kept":726,"cut":false,"hidden":false,"merged":[[18,13,18,14],[87,13,87,14],[95,13,95,14],[96,13,96,14],[105,13,105,14],[106,13,106,14],[107,13,107,14],[108,13,108,14],[109,13,109,14],[99,13,99,14],[100,13,100,14],[101,13,101,14],[102,13,102,14],[103,13,103,14],[104,13,104,14],[91,13,91,14],[92,13,92,14],[93,13,93,14],[94,13,94,14],[97,13,97,14],[98,13,98,14],[83,13,83,14],[84,13,84,14],[85,13,85,14],[488,13,488,14],[489,13,489,14],[497,13,497,14],[595,13,595,14],[629,13,629,14],[695,13,695,14],[479,13,479,14],[480,13,480,14],[481,13,481,14],[482,13,482,14],[483,13,483,14],[484,13,484,14],[485,13,485,14],[486,13,486,14],[487,13,487,14],[470,13,470,14],[471,13,471,14],[472,13,472,14],[473,13,473,14],[474,13,474,14],[475,13,475,14],[476,13,476,14],[477,13,477,14],[478,13,478,14],[462,13,462,14],[463,13,463,14],[464,13,464,14],[465,13,465,14],[466,13,466,14],[467,13,467,14],[468,13,468,14],[469,13,469,14],[453,13,453,14],[454,13,454,14],[455,13,455,14],[456,13,456,14],[457,13,457,14],[458,13,458,14],[459,13,459,14],[460,13,460,14],[461,13,461,14],[444,13,444,14],[445,13,445,14],[446,13,446,14],[447,13,447,14],[448,13,448,14],[449,13,449,14],[450,13,450,14],[451,13,451,14],[452,13,452,14],[436,13,436,14],[437,13,437,14],[438,13,438,14],[439,13,439,14],[440,13,440,14],[441,13,441,14],[442,13,442,14],[443,13,443,14],[428,13,428,14],[429,13,429,14],[430,13,430,14],[431,13,431,14],[432,13,432,14],[433,13,433,14],[434,13,434,14],[435,13,435,14],[419,13,419,14],[420,13,420,14],[421,13,421,14],[422,13,422,14],[423,13,423,14],[424,13,424,14],[425,13,425,14],[426,13,426,14],[427,13,427,14],[410,13,410,14],[411,13,411,14],[412,13,412,14],[413,13,413,14],[414,13,414,14],[415,13,415,14],[416,13,416,14],[417,13,417,14],[418,13,418,14],[401,13,401,14],[402,13,402,14],[403,13,403,14],[404,13,404,14],[405,13,405,14],[406,13,406,14],[407,13,407,14],[408,13,408,14],[409,13,409,14],[392,13,392,14],[393,13,393,14],[394,13,394,14],[395,13,395,14],[396,13,396,14],[397,13,397,14],[398,13,398,14],[399,13,399,14],[400,13,400,14],[387,13,387,14],[388,13,388,14],[389,13,389,14],[390,13,390,14],[391,13,391,14],[378,13,378,14],[379,13,379,14],[380,13,380,14],[381,13,381,14],[382,13,382,14],[383,13,383,14],[384,13,384,14],[385,13,385,14],[386,13,386,14],[367,13,367,14],[368,13,368,14],[369,13,369,14],[370,13,370,14],[373,13,373,14],[374,13,374,14],[375,13,375,14],[376,13,376,14],[377,13,377,14],[357,13,357,14],[359,13,359,14],[360,13,360,14],[361,13,361,14],[362,13,362,14],[363,13,363,14],[364,13,364,14],[365,13,365,14],[366,13,366,14],[358,13,358,14],[346,13,346,14],[347,13,347,14],[348,13,348,14],[349,13,349,14],[350,13,350,14],[351,13,351,14],[352,13,352,14],[353,13,353,14],[356,13,356,14],[329,13,329,14],[330,13,330,14],[332,13,332,14],[335,13,335,14],[337,13,337,14],[338,13,338,14],[339,13,339,14],[340,13,340,14],[344,13,344,14],[331,13,331,14],[333,13,333,14],[334,13,334,14],[336,13,336,14],[341,13,341,14],[342,13,342,14],[343,13,343,14],[320,13,320,14],[321,13,321,14],[322,13,322,14],[323,13,323,14],[324,13,324,14],[325,13,325,14],[326,13,326,14],[327,13,327,14],[328,13,328,14],[311,13,311,14],[312,13,312,14],[313,13,313,14],[314,13,314,14],[315,13,315,14],[316,13,316,14],[317,13,317,14],[318,13,318,14],[319,13,319,14],[302,13,302,14],[303,13,303,14],[304,13,304,14],[305,13,305,14],[306,13,306,14],[307,13,307,14],[308,13,308,14],[309,13,309,14],[310,13,310,14],[293,13,293,14],[294,13,294,14],[295,13,295,14],[296,13,296,14],[297,13,297,14],[298,13,298,14],[299,13,299,14],[300,13,300,14],[301,13,301,14],[284,13,284,14],[285,13,285,14],[286,13,286,14],[287,13,287,14],[288,13,288,14],[289,13,289,14],[290,13,290,14],[291,13,291,14],[292,13,292,14],[277,13,277,14],[278,13,278,14],[279,13,279,14],[280,13,280,14],[281,13,281,14],[282,13,282,14],[283,13,283,14],[268,13,268,14],[269,13,269,14],[270,13,270,14],[271,13,271,14],[272,13,272,14],[273,13,273,14],[274,13,274,14],[275,13,275,14],[276,13,276,14],[259,13,259,14],[260,13,260,14],[261,13,261,14],[262,13,262,14],[263,13,263,14],[264,13,264,14],[265,13,265,14],[266,13,266,14],[267,13,267,14],[250,13,250,14],[251,13,251,14],[252,13,252,14],[253,13,253,14],[254,13,254,14],[255,13,255,14],[256,13,256,14],[257,13,257,14],[258,13,258,14],[241,13,241,14],[242,13,242,14],[243,13,243,14],[244,13,244,14],[245,13,245,14],[246,13,246,14],[247,13,247,14],[248,13,248,14],[249,13,249,14],[235,13,235,14],[236,13,236,14],[237,13,237,14],[238,13,238,14],[239,13,239,14],[240,13,240,14],[227,13,227,14],[228,13,228,14],[229,13,229,14],[230,13,230,14],[231,13,231,14],[232,13,232,14],[233,13,233,14],[234,13,234,14],[218,13,218,14],[219,13,219,14],[220,13,220,14],[221,13,221,14],[222,13,222,14],[223,13,223,14],[224,13,224,14],[225,13,225,14],[226,13,226,14],[209,13,209,14],[210,13,210,14],[211,13,211,14],[212,13,212,14],[213,13,213,14],[214,13,214,14],[215,13,215,14],[216,13,216,14],[217,13,217,14],[201,13,201,14],[202,13,202,14],[203,13,203,14],[204,13,204,14],[205,13,205,14],[206,13,206,14],[207,13,207,14],[208,13,208,14],[195,13,195,14],[196,13,196,14],[197,13,197,14],[198,13,198,14],[199,13,199,14],[200,13,200,14],[186,13,186,14],[187,13,187,14],[188,13,188,14],[189,13,189,14],[190,13,190,14],[191,13,191,14],[192,13,192,14],[193,13,193,14],[194,13,194,14],[177,13,177,14],[178,13,178,14],[179,13,179,14],[180,13,180,14],[181,13,181,14],[182,13,182,14],[183,13,183,14],[184,13,184,14],[185,13,185,14],[168,13,168,14],[169,13,169,14],[170,13,170,14],[171,13,171,14],[172,13,172,14],[173,13,173,14],[174,13,174,14],[175,13,175,14],[176,13,176,14],[159,13,159,14],[160,13,160,14],[161,13,161,14],[162,13,162,14],[163,13,163,14],[164,13,164,14],[165,13,165,14],[166,13,166,14],[167,13,167,14],[150,13,150,14],[151,13,151,14],[152,13,152,14],[153,13,153,14],[154,13,154,14],[155,13,155,14],[156,13,156,14],[157,13,157,14],[158,13,158,14],[141,13,141,14],[142,13,142,14],[143,13,143,14],[144,13,144,14],[145,13,145,14],[146,13,146,14],[147,13,147,14],[148,13,148,14],[149,13,149,14],[133,13,133,14],[134,13,134,14],[135,13,135,14],[136,13,136,14],[137,13,137,14],[138,13,138,14],[139,13,139,14],[140,13,140,14],[124,13,124,14],[125,13,125,14],[126,13,126,14],[127,13,127,14],[128,13,128,14],[129,13,129,14],[130,13,130,14],[131,13,131,14],[132,13,132,14],[116,13,116,14],[117,13,117,14],[118,13,118,14],[119,13,119,14],[120,13,120,14],[121,13,121,14],[122,13,122,14],[123,13,123,14],[110,13,110,14],[112,13,112,14],[113,13,113,14],[114,13,114,14],[115,13,115,14],[111,13,111,14],[86,13,86,14],[88,13,88,14],[89,13,89,14],[90,13,90,14],[74,13,74,14],[75,13,75,14],[76,13,76,14],[77,13,77,14],[78,13,78,14],[79,13,79,14],[80,13,80,14],[81,13,81,14],[82,13,82,14],[65,13,65,14],[66,13,66,14],[67,13,67,14],[68,13,68,14],[69,13,69,14],[70,13,70,14],[71,13,71,14],[72,13,72,14],[73,13,73,14],[56,13,56,14],[57,13,57,14],[58,13,58,14],[59,13,59,14],[60,13,60,14],[61,13,61,14],[62,13,62,14],[63,13,63,14],[64,13,64,14],[47,13,47,14],[48,13,48,14],[49,13,49,14],[50,13,50,14],[51,13,51,14],[52,13,52,14],[53,13,53,14],[54,13,54,14],[55,13,55,14],[39,13,39,14],[40,13,40,14],[41,13,41,14],[42,13,42,14],[43,13,43,14],[44,13,44,14],[45,13,45,14],[46,13,46,14],[30,13,30,14],[31,13,31,14],[32,13,32,14],[33,13,33,14],[34,13,34,14],[35,13,35,14],[36,13,36,14],[37,13,37,14],[38,13,38,14],[1,0,1,8],[7,1,7,2],[5,1,5,2],[6,1,6,2],[4,1,4,2],[2,0,2,8],[9,13,9,14],[11,13,11,14],[10,13,10,14],[345,13,345,14],[354,13,354,14],[355,13,355,14],[371,13,371,14],[372,13,372,14],[358,9,358,10],[8,6,8,8],[12,13,12,14],[13,13,13,14],[14,13,14,14],[15,13,15,14],[16,13,16,14],[17,13,17,14],[19,13,19,14],[20,13,20,14],[21,13,21,14],[22,13,22,14],[23,13,23,14],[24,13,24,14],[25,13,25,14],[26,13,26,14],[27,13,27,14],[28,13,28,14],[29,13,29,14]]}
["[The EHR Solution]  Information Security Assessment"]
["Instructions:"]
["1. Use the check boxes to select the role(s) that your organization is undertaking and then click Filter Requirements. Refer to the site profile tab for definitions and scope of source policy and for definitions of each role.\n2. For each policy statement below please select a response from the Status and Expected Implementation Date columns.  In the HIC Comments column, add sufficient detail about the control implementation at your organization. For example, reference an internal policy, practice or control that has been implemented.  This will enable your executive sponsor to attest to the controls your organization has put in place, allow for the re-use and interpretation of this assessment in the future by your organization.\n3. When complete, password protect the document using a strong password and submit it to connecting.security@ehealthontario.on.ca, phone the Connecting Security Team with the password to decrypt.  "]
["Legend",null,null,null,null,null,"SELECT THE RELEVANT ROLES FOR YOUR ORGANIZATION",null,null,"LEGEND"]
["Status Code","Meaning",null,null,null,false,null,null,null,"Must Policy Statement"]
["I","Control is Implemented or similar / equivalent control exists (please describe equivalent or similar controls)",null,null,null,false,null,null,null,"Should Policy Statement","Viewer"]
["NI","Control is Not Implemented - remediation is required.",null,null,null,false,null,null,null,null,"Contributor"]
["NA (Not Applicable)","Control is Not Applicable for the organization. (please provide rationale for excluding control)",null,null,null,false,null,null,null,null,"Identity Provider"]
[]
["Policy reference ","Source Policy","Control description ","Must / Should","Function","Applicable Role","Status","Expected Implementation Date","HIC Comments","Program Office Comments",null,"Implementation Guidance","Scope Considerations","ONE ID and other Reference Materials"]
[null,"Acceptable Use of Information and Information Technology Standard v2.0",null,null,null,"null"]
[1.1000000000000001,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must always use assigned credential to participate in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganizations must ensure unique credentials are given to each staff and should update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.2,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must never allow another person to use their credentials to participate in [the EHR Solution]. All persons are accountable for any actions performed on [the EHR Solution] with their ID.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganizations must ensure unique credentials are given to each staff and should update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.3,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must never participate in [the EHR Solution] unless their role requires them to do so, they are expressly authorized to do so, it is necessary to do so (e.g., providing or assisting in the provision of healthcare), and in accordance with their respective HIC’s or [the EHR Solution]’s privacy policies.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.4,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must never disable, override or willfully bypass any information security control when participating in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.5,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must never attempt to exploit any suspected security weakness on [the EHR Solution], even to explore that such a weakness may exist, unless it is part of their assigned job duties or responsibilities and they are explicitly authorized to do so.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.6,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must never knowingly perform an act that will interfere with the normal operations of [the EHR Solution], or try to disrupt [the EHR Solution] by either intentionally making the solution unavailable or by affecting the integrity of the data being stored in or processed for the participation in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.7,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must abide by the terms and conditions of [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant. An End User Agreement is presented to the user of the Provider Portal to bind them to terms of using the solution.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.8,"Acceptable Use of Information and Information Technology Standard v2.0","All users must lock their computing devices when leaving their device unattended while logged on to [the EHR Solution] within the HIC’s premises.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant. If your organization does not have a policy, a sample can be provided.","Scope is limited to human behaviours and system interacting with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.9,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must use [the EHR Solution] or HIC-approved tools and processes to participate in [the EHR Solution].","Must","Top Management","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials however HIC must review the access methods that are approved and ensure that they meet the principals of the EHR Policy.\n\nEnsure that Agents and ESP are aware of appropriate and inappropriate ways to access the EHR Solution.","Approved tools and processes are methods that the HIC has endorsed which meet the requirements of the EHR Policies.\n\nRequirements include but are not limited to:\n\n- 2 factor authentication for remote access\n- Harddrive encryption where files are being stored locally. (Note files may be downloaded to the device while using the solution).\n- Remote access methods approved by the HIC.\nAntivirus or malware detection software","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.1000000000000001,"Acceptable Use of Information and Information Technology Standard v2.0","HICs, their Agents and Electronic Service Providers must never take a picture of data displayed on [the EHR Solution].","Must","Top Management","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.1100000000000001,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must only email PHI to [the EHR Solution] Program Office when it is necessary for the purposes of providing or assisting in the provision of health care or [the EHR Solution] business, and is acceptable under their respective HIC’s and [the EHR Solution]’s policies or procedures.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.\n\nONE Mail is acceptable as a method to communicate PHI however this information must not be communicated to the Program Office Service Desk initially, a member from eHealth Ontario will contact you if PHI is to be sent.\n\nIf ONE Mail is not used then encryption should be applied to the data in transit, either through a strong password in a MS Office document or with WinZip. See password requirements in this Policy and ensure that the password is communicated in an out of band method (i.e. telephone).","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.1200000000000001,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must either encrypt emails that contain PHI, use a secure file transfer solution or use a secure e-mail system approved by their respective HIC or [the EHR Solution].","Must","Top Management","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.\n\nONE Mail is acceptable as a method to communicate PHI however this information must not be communicated to the Program Office Service Desk.  If ONE Mail is not used then encryption should be applied to the data in transit, either through a strong password in a MS Office document or with WinZip. See password requirements in this Policy and ensure that the password is communicated in an out of band method (i.e. telephone).","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.1299999999999999,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never use external email accounts (e.g., Hotmail, or Gmail) to send PHI to or receive PHI from [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.1399999999999999,"Acceptable Use of Information and Information Technology Standard v2.0","Where possible, should use phrases (e.g., IL0v3EatingP!zza) when creating passwords used to participate in [the EHR Solution].","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant. If your organization does not have a policy, a sample can be provided.","Scope is limited to human behaviours and system interacting with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.1499999999999999,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must always create passwords used to participate in [the EHR Solution] that are at least eight characters, with a maximum not less than 64 characters long, and include at least three of the following conditions of complexity:\n- One number\n- One uppercase letter\n- One lowercase letter, or\n- One special character.\nTo permit no complexity, live screening of new passwords must be completed and displayed to users during password creation. Live screening must be done against a list of commonly used passwords: blacklist, dictionary, usernames, service names, sequential strings, passwords from previous breaches. ","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"ONE ID accounts meet this requirement by default however strong passwords need to be configured on devices used to access the EHR Solution in the event PHI is downloaded or saved to that device. \n\nOrganizations using other accounts must verify with their IT staff or vendor if an upgrade is possible to address the issue.\n\nIntegrate authentication into Active Directory is an option where the HSP is relying on the HIS for credentials.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.1599999999999999,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never create passwords used to participate in [the EHR Solution] that include:\n- All or part of their ID\n- Easily obtained personal information about themselves (e.g., names of family members, pets, birthdays, anniversaries, hobbies)\n- Three consecutive characters (e.g., AAA).","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant. Consider if technical capabilities are possible, otherwise ensure the training messages include this.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.17,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must choose passwords used to participate in [the EHR Solution] that are easy to remember but hard to guess by someone else.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.\n","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.18,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never change passwords used to participate in [the EHR Solution] in an easily recognized pattern (e.g., changing “IL0v3EatingP!zza1” to “IL0v3EatingP!zza2”).","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.19,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must ensure their passwords used to participate in [the EHR Solution] are different from their password(s) used to participate in other accounts (e.g., corporate e-mail account, personal banking, etc.).","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.2,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must commit passwords used to participate in [the EHR Solution] to memory. All persons must avoid keeping a record of their passwords (e.g., on paper, or stored on in a file), unless it:\n- Can be stored securely, and\n- Does not indicate the associated ID or that it is for [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant\n","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.21,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must keep their passwords used to participate in [the EHR Solution] a secret, never telling anyone their password, including a system administrator, help desk personnel or a manager.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications and passwords used to manage devices accessing the EHR Solution.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.22,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must immediately change their password used to participate in [the EHR Solution] if they suspect or confirm that their password has been disclosed or compromised and notify their information security incident initial point of contact (e.g. a helpdesk or Privacy Officer) of the security incident, see “Reporting Information Security Incidents Related to [the EHR Solution] below.","Must","Top Management","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy over time. Include in the incident management protocol developed\n","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.23,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must not include their ID or password used to participate in [the EHR Solution] in any automated single sign-on process (SSO) (e.g., stored in a macro or function key) except [EHR Solution] approved SSO management systems.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.  Organizations must ensure that the SSO solutions used are approved by the EHR Solution Program","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications and passwords used to manage devices accessing the EHR Solution.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.24,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must always change any password used to participate in [the EHR Solution] that is provided to them at initial login and as directed by their Identity Provider.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nBy default ONE ID accounts will require the initial password to be changed.\n\nOrganization must update their own policy over time.  \n\nOrganizations must review the configuration of their authentication system / password reset process and ensure that they can mark the account password to be changed on the first login.    Active Directory authentication typically has this capability.\n","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications and passwords used to manage devices accessing the EHR Solution.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.25,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must use a [the EHR Solution] or HIC-approved remote participate in solution (e.g., through a virtual private network or terminal services) to remotely participate in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials however HIC must review the access methods that are approved and ensure that they meet the principals of the EHR Policy.\n\nEnsure that Agents and ESP are aware of appropriate and inappropriate ways to access the EHR Solution remotely.","Approved remote access solution are those methods developed and endorsed by the HIC which meet the requirements of the EHR Policies.\n\nRequirements include but are not limited to:\n\n- 2 factor authentication for remote access\n- Hard drive encryption where files are being stored locally.\n- Remote access methods approved by the HIC.\n- Antivirus or malware detection software\n","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.26,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must follow the proper procedures to disconnect from a remote participate in connection used to participate in [the EHR Solution] (e.g., if the remote participate in solution has a disconnect option, use this option to disconnect rather than simply closing the application).","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy over time.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.27,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never participate in [the EHR Solution] in an area where unauthorized individuals can view the information (e.g., Internet cafés, public transit, and other non-private settings).","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy over time.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.28,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never leave their mobile computing device that has the ability to participate in [the EHR Solution] unattended in a public place.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy over time.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.29,"Acceptable Use of Information and Information Technology Standard v2.0","When required to leave their mobile computing device in a vehicle, all persons must place it out of view and lock the vehicle..","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy over time.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.3,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must ensure that if personal health or personal information is downloaded onto a mobile device from [the EHR Solution], the location where the data is stored is encrypted or the end user tool utilizes full disk encryption. Full disk encryption is the preferred option on mobile devices however containerized implementations of encryption on shared personal and corporate devices are also acceptable.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy over time. Organization must verify if full disk encryption is enabled and if strong passwords and appropriate algorithms are in place to protect the encrypted data. See crypto policy for algorithms.","Scope is limited to interaction with the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.31,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must immediately report suspected or confirmed information security incidents related to [the EHR Solution] to their information security incident initial point of contact (e.g., a help desk or Privacy Officer). Alternatively, HICs may instruct agents to report the incident to their manager or supervisor, who in turn must report it to the information security incident initial point of contact.","Must","Top Management","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must establish that point of contact and the incident management procedures.  Policy and procedure updates are required to make this operational before go live.","Scope is limited to incidents related to the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[1.32,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must provide their full cooperation to [the EHR Solution] Program Office, their agents or Electronic Service Providers with any information security incident investigation.","Must","Top Management","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy to be compliant.","Scope is limited to incidents related to the EHR Solution, including all Patient Portals/Applications.","A sample Acceptable Use and Information Security Policy is available from the Connecting Ontario Security Team"]
[2.1,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must always use their assigned ID and password to participate in [the EHR Solution].","Must",null,"Program Office"]
[2.2000000000000002,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must never allow another person to use their ID to participate in [the EHR Solution]. All persons are accountable for any actions performed with their ID on [the EHR Solution].","Must",null,"Program Office"]
[2.2999999999999998,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must never participate in [the EHR Solution] unless their role requires them to do so, they are expressly authorized to do so, it is necessary to do so (e.g., providing or assisting in the provision of healthcare), and in accordance with [the EHR Solution]’s privacy policies.","Must",null,"Program Office"]
[2.4,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must never disable or override any information security controls (e.g., disabling anti-virus protection on their workstation).","Must",null,"Program Office"]
[2.5,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must only use tools and processes [the EHR Solution] approves and endorses to participate in [the EHR Solution].","Must",null,"Program Office"]
[2.6,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must never attempt to exploit any suspected security weakness, even to explore that such a weakness may exist, unless it is part of their assigned job duties or responsibilities and they are explicitly authorized by [the EHR Solution] Program Office to do so.","Must",null,"Program Office"]
[2.7,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must never knowingly perform an act that will interfere with the normal operations of [the EHR Solution], or try to disrupt [the EHR Solution] by either intentionally making such services unavailable or by affecting the integrity of the data being stored in or processed by [the EHR Solution].","Must",null,"Program Office"]
[2.8,"Acceptable Use of Information and Information Technology Standard v2.0","Agents and Electronic Service Providers of [the EHR Solution] (“all persons”) must abide by the terms and conditions of [the EHR Solution] provided.","Must",null,"Program Office"]
[2.9,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never discuss PHI with any person that does not have a need-to-know or is not authorized to know the information.","Must",null,"Program Office"]
[2.1,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never discuss PHI in public areas, including elevators, as it may be easily overheard by those who do not have a need-to-know.","Must",null,"Program Office"]
[2.11,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must lock up PHI in any form (e.g., locking paper, printed copies originating from the [EHR Solution] or portable storage media in a cabinet) when left unattended in an unsecured area, especially when the office or area is vacated.","Must",null,"Program Office"]
[2.12,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must always log-off or lock unattended computers or workstations to prevent unauthorized individuals from accessing PHI.","Must",null,"Program Office"]
[2.13,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must only store PHI on [the EHR Solution]-approved devices or storage networks, and only store the minimal amount of PHI necessary on any encrypted portable storage media.","Must",null,"Program Office"]
[2.14,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must always ensure that paper documents containing PHI are shredded or placed in a secure shredding receptacle when they are no longer needed.","Must",null,"Program Office"]
[2.15,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must follow internal procedures for the proper secure disposal of any information technology that may have PHI stored on it.","Must",null,"Program Office"]
[2.16,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must only email PHI when it is necessary for the purposes of providing or assisting in the provision of health care or [the EHR Solution] business, and is acceptable under [the EHR Solution]’s policies or procedures.","Must",null,"Program Office"]
[2.17,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must encrypt all emails that contain PHI, use a secure file transfer solution or use a secure email system approved by [the EHR Solution].","Must",null,"Program Office"]
[2.1800000000000002,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never use external email accounts (e.g., Hotmail, or Gmail) to send or receive PHI.","Must",null,"Program Office"]
[2.19,"Acceptable Use of Information and Information Technology Standard v2.0","All persons should where possible, use phrases (e.g., IL0v3EatingP!zza) when creating passwords.","Should",null,"Program Office"]
[2.2000000000000002,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must always create passwords used to participate in [the EHR Solution] that are at least eight characters, with a maximum not less than 64 characters long, and include at least three of the following conditions of complexity:\n- One number\n- One uppercase letter\n- One lowercase letter, or\n- One special character.\nTo permit no complexity, live screening of new passwords must be completed and displayed to users during password creation. Live screening must be done against a list of commonly used passwords: blacklist, dictionary, usernames, service names, sequential strings, passwords from previous breaches. ","Must",null,"Program Office"]
[2.21,"Acceptable Use of Information and Information Technology Standard v2.0","All person must never create passwords that include:\n- All or part of their ID\n- Easily obtained personal information about themselves (e.g., names of family members, pets, birthdays, anniversaries, hobbies).\n- Three consecutive characters (e.g., AAA)","Must",null,"Program Office"]
[2.2200000000000002,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must choose passwords that are easy to remember but hard to guess by someone else.","Must",null,"Program Office"]
[2.23,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never change passwords in an easily recognized pattern (e.g., changing “IL0v3EatingP!zza1” to “IL0v3EatingP!zza2”).","Must",null,"Program Office"]
[2.2400000000000002,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must ensure that their passwords used to participate in [the EHR Solution] are different from their password(s) used to participate in other accounts (e.g., corporate e-mail account, personal banking, etc.).","Must",null,"Program Office"]
[2.25,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must commit their passwords to memory. All persons must avoid keeping a record of their passwords (e.g., on paper, or stored on in a file), unless it:\n- Can be stored securely, and\n- Does not indicate the ID, information system or information technology for which the ID is associated.","Must",null,"Program Office"]
[2.2599999999999998,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must keep their passwords a secret, never telling anyone their password, including a system administrator, help desk personnel or a manager.","Must",null,"Program Office"]
[2.27,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must change their password immediately if they suspect or confirm that their password has been disclosed or compromised.","Must",null,"Program Office"]
[2.2799999999999998,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must not include their ID or password in any automated sign-on process (e.g., stored in a macro or function key).","Must",null,"Program Office"]
[2.29,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must always change passwords that are provided to them at initial login.","Must",null,"Program Office"]
[2.2999999999999998,"Acceptable Use of Information and Information Technology Standard v2.0","All person must use a [the EHR Solution] approved remote access solution (e.g., through a virtual private network or terminal services) to remotely participate in [the EHR Solution].","Must",null,"Program Office"]
[2.31,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must follow the proper procedures to disconnect from remote access (e.g., if the remote access solution has a disconnect option, use this option to disconnect rather than simply closing the application).","Must",null,"Program Office"]
[2.3199999999999998,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never participate in [the EHR Solution] in an area where unauthorized individuals can view the information (e.g., Internet cafés, public transit, and other non-private settings).","Must",null,"Program Office"]
[2.33,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must never leave their mobile computing device that has the ability to participate in [the EHR Solution] unattended in a public place.","Must",null,"Program Office"]
[2.34,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must when required to leave their mobile computing device in a vehicle, lock it in the trunk or place it out of view before getting to your destination. If you get to the destination before securing the device you should take it with you instead.","Must",null,"Program Office"]
[2.35,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must immediately report suspected or confirmed information security incidents to [the EHR Solution] information security incident initial point of contact (e.g., a help desk). Alternatively, agents may report the incident to their manager or supervisor, who in turn must report it to the information security incident initial point of contact.\nExamples of information security incidents include, but are not limited to:\n- Unauthorized disclosure of PHI.\n- Theft or loss of information technology that contains PHI even if it is encrypted.\n- Virus or malware infection on a device that has access to [the EHR Solution].\n- Attempts (either failed or successful) to gain unauthorized access to [the EHR Solution].\n- Compromised password, i.e., another individual knows your password.","Must",null,"Program Office"]
[2.36,"Acceptable Use of Information and Information Technology Standard v2.0","All persons must provide their full cooperation to [the EHR Solution] Program Office, their agents or Electronic Service Providers with any information security incident investigation.","Must",null,"Program Office"]
[null,"Access Control and Identity Management for System Level Access Standard v1.9",null,null,null,"null"]
[1.1000000000000001,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must clearly define and document the information security responsibilities of all their agents and Electronic Service Providers with access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution]. These responsibilities may be combined with, or already covered by other information security responsibilities specified by the HIC.","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Connecting Ontario training courses includes some messaging with regards to security responsibilities. Organizations should update internal policies or other documentation to point to security responsibilities for Agents and ESPs with access to these components.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.2,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must implement a process to verify job application information for all new agents or Electronic Service Providers who will have access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution]. Verification methods may include:\n\n- Character or employment references\n- Criminal record checks where possible taking into consideration employment arrangements of the organization and unions.\n- Verification of prior experience, academic record, and professional qualifications, and\n- Verification of identity from government issued identification.","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Consider reviewing existing HR and Procurement contracts.  Importantly understand what ESPs provide services for your organization that support the Data Contribution and Identity Provider activities.  See the ESP policy for suggested scope considerations.\n\nOrganizations should consider if the existing processes used to verify existing Agents and ESPs was sufficient.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.3,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that all their new agents and Electronic Service Providers who will have access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] agree to maintain the security of personal health information (PHI). At a minimum, the terms and conditions of employment must:\n\n- Require adherence to their information security-related policies\n- Explain the agent or Electronic Service Provider’s legal responsibilities and rights, e.g., regarding protection of information or privacy legislation\n- Include a non-disclosure/confidentiality clause that extends after employment, and\n- State that information security responsibilities extend outside normal working hours, premises and networks, and continue after employment has ended.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policies. ","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.4,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that all access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] is provisioned based on the requestor’s established business needs, in accordance with their privacy policies, and in accordance with the principles of need-to-know and least-privilege (i.e., an agent or Electronic Service Provider is granted only the minimum access privileges required).\n\nHICs are responsible for identifying all their agents and Electronic Service Providers who require access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations must develop an approval process to provide access to the supporting infrastructure.     \n\nBasic roles should be created, Requestor (sysadmin);  Sponsor (person who approves - typically a management position responsible for resources).   At minimum, an email trail of requests and approvals must be maintained. Integration into a ticketing system could be considered as well.\n\nThe key to this control is to ensure that access is on a \"need to know\", \"least privilege\" principle.  Only those who require access to the system should be given access.  ","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.5,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must assign, and authentication services must ensure: that user ID’s, Service IDs, and/or digital certificates/ Secure ID Tokens are unique and traceable to a single person when these are used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution]. ","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Unique IDs must be used to access the data contributor and identity provider infrastructure. \n\nIf shared accounts are used to do system administration then those should be replaced  by uniquely named accounts.   Mimic permissions that were assigned to the shared account and provide those privileges to the required system admins.\n\nFor UNIX systems, organizations should leverage the SUDO command to allow users to switch from a personal ID to a root or shared admin ID.  This SUDO activity must be logged and collected according to the Security Logging and Monitoring Policy.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.6,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must configure their access control and identity management systems to deny access by default to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] (i.e., access must be explicitly authorized).","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Deny by default is typically implemented out of the box for systems.   Organizations should ensure that access permissions for the systems in scope have not been left open and that access requires a written request and technical enablement.\n\nOrganizations should consider using a combinations of \"role\" and \"access\" groups to manage access.   Role groups can be developed for roles such as \"DBAdmin\", \"FWAdmin\", etc.   Various access groups are created and assigned to specific permissions in technologies or consoles, those access groups are then attached to a role that has been developed.    Individuals can then be placed into a role group and avoid having accounts created on individual consoles and infrastructure systems.  This make provisioning and revocation of access easier. ","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.7,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must require the creation or amendment of a user ID that will have access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] to be initiated by a written or electronic request (e.g., via an email or help desk ticket) that is approved by a Sponsor. The request for ID creation must contain access privileges requested and may contain the following information:\n\n- The Sponsor’s details: full name, department, sponsor authority, location, and contact information (email and telephone number (where available))\n- Details of whom the ID is to be assigned to: full name, department and location, and contact information (email and telephone number (where available))","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations must develop an approval process to provide access to the supporting infrastructure.     \n\nBasic roles should be created, Requestor (sysadmin);  Sponsor (person who approves - typically a management position responsible for resources).  At minimum, an email trail of requests and approvals must be maintained.\n\nIntegration into a ticketing system could be considered as well.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.8,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must maintain a log of all requests for user IDs that they administer and will have access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider "]
[1.9,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must maintain a list of all individuals that have access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution]. The list must include the following:\n\n- The ID, and\n- Person or information system’s details: Full name, department, and location, and contact information (email and telephone number (where available)).","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"An organization must maintain a list of IDs and include the required information. \n\n","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.1000000000000001,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must review a list of user IDs and authorizations that they administer and that have access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] annually to ensure that authorized access remains appropriate, and must request modifications, suspensions, or revocations to privileges where inappropriate access is identified.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations can leverage the list from above to review who has access to the systems in scope and compare it against a list of those approved for access.  Changes to the list should match up with the log of access changes over the period.  Anomalies must be investigated and remediated.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.1100000000000001,"Access Control and Identity Management for System Level Access Standard v1.9","Upon termination of employment, contractual or other relationship, or a change in job duties or responsibilities, HICs must review and if necessary request a modification, suspension or revocation of access privileges on the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] for their agents or Electronic Service Providers.","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations must develop a process to adjust / revoke access to the systems in scope as responsibilities change or due to terminations, etc.  Organizations should consider what HR and procurement practices are in place and develop processes that integrate with those. \n\nWhere accounts are integrated into a central directory service, revoking access my be easier but do not forget about access that may not be integrated with the organization's central directory. (e.g. external administrator portals, 3rd party cloud applications, etc.)","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.1200000000000001,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must suspend IDs that have access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] after 180 consecutive days (or 6 months) of inactivity either manually or automatically. HICs may send the user of the ID an email warning them of the imminent suspension.","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations leveraging a central directory service have the capability to put technical policies in place that will suspend accounts after 180 days without a login.\n\nOtherwise, a semi-annual manual review of accounts could be implemented, this would involve a verification with the Sponsor / Requestor, that the access is still necessary.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.1299999999999999,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must not name Privileged IDs on their identity provider services and data contribution endpoints in a way that provides any indication of the ID’s privilege level.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should consider a naming convention for privileged and service IDs.   Often conventions such as org-name.number could be used.   (XYZHospital.123), this would not infer anything about what this account has access to.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.1399999999999999,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must not assign privileged entitlements on their identity provider services and data contribution endpoints to a Personal ID. Persons requiring privileged access on a HIC’s identity provider services and data contribution endpoints must be assigned a Privileged ID, and a Personal ID to be used for normal business activities.\n","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"The intention is to separate a day-to-day account used for email or browsing the Internet with those used to do system administration or running a system service.  \n\nThis will help protect ongoing operations of your systems.  For example, preventing malicious code from the Internet or Email from executing under the context of a Privileged ID.   Or if a personal ID is locked out due to failed password guesses and this personal ID is also running a critical service such as a Database service, the system may halt.\n\nFailure to follow this practice can also make it difficult to revoke accounts if the individual leaves the organization.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.1499999999999999,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that the assignment and use of Privileged IDs on their identity provider services and data contribution endpoints is limited to the minimum number of persons who are directly responsible for operational support or administration.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations must develop an approval process to provide access to the supporting infrastructure.     \n\nThe key to this control is to ensure that access is on a \"need to know\", \"least privilege\" principle.  Only those who require access to the system should be given access.  ","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.1599999999999999,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that the names of Service IDs on their identity provider services and data contribution endpoints are different from the system names on which the Service IDs are created.","Must",null,"Data Contributor \nIdentity Provider "]
[1.17,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that an identified owner(s) is assigned to each service ID and maintained in an inventory.","Must",null,"Data Contributor \nIdentity Provider "]
[1.18,"Access Control and Identity Management for System Level Access Standard v1.9","HICs may use a non-expiring password for Service IDs on their identity provider services and data contribution endpoints with credentials that are incapable of being used by a person.","Should",null,"Data Contributor \nIdentity Provider "]
[1.19,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that a Service ID on their identity provider services and data contribution endpoints with credentials that are capable of being used by a person and are embedded into an automated process have their passwords changed to a new password either:\n\n- Whenever the technology changes\n- After an actual or suspected password compromise, or\n- After turnover of any person that knows the password.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"If possible make the Service ID non-interactive meaning that no individual is able to log on.  Also, determine if the password must even be kept or if it could be implemented through split knowledge.  This would prevent anyone from knowing the password in the event they departed from the organization.\n\nThe other two triggers for account changes are when technology changes which should be fairly infrequent and should be part of a project to build systems.  Where an incident occurs, part of the containment procedures should involve account changes of accounts impacted.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.2,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must communicate initial passwords or passphrases (“passwords”) used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] securely.\n\n","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Passwords must be communicated through a secure means, consider options such as:\n\n- a self serve password portal\n- delivery through telephone after positive identification of users\n- physical delivery in person\n\nEmail should not be used to communicated passwords.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.21,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must set initial passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] to prompt the user to change their password at initial login or must ensure that the user is manually instructed to change their password at initial login.\n","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Behaviour requirements are communicated in the Connecting Ontario training materials.\n\nOrganization must update their own policy and review the configuration of their authentication system / password reset process and ensure that they can mark the account password to be changed on the first login.    Active Directory authentication typically has this capability.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.22,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] are masked or concealed on entry, i.e., represented on the screen by a special character such as an asterisk. Temporary visibility of passwords is permitted depending on technology limitations.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"By default, most systems would suppress displaying the password characters when typed in.   This is often a configurable option.\n\nIf not compliant, the organization should confirm with the vendor if a future release supports this feature.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.23,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure their information systems are technically capable of accepting User passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] that meet the Personal ID password requirements and ensure compliance with the account lockout, lockout duration, history and minimum age requirements for passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution]. See Appendix A.\n","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should consider if their infrastructure and authentication mechanisms can be integrated into a central directory system where these items can be enforced through a technical policy.  \n\nActive Directory will support these requirements.\n\nWhere a system may not support all the password requirements, highlight the items that can not be met and consider some mitigating approaches that could be considered in the interim. E.g. increase password length if all complexity attributes can not be met.  Discuss these with the Connecting Ontario Security Team.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.24,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must only reset a password used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] after the user’s identity has been successfully verified.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Passwords should be communicated through a means such as:\n\n- a self serve password portal\n- telephone after positive identification of users\n- physical or in person\n\nEmail should not be used to communicated passwords.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.25,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must encrypt passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] in transmission.","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should ensure they are using secure authentication implementations, for example Kerberos on a Windows system. On UNIX systems review the  /etc./shadow or /etc./passwd\n\nEnsure that Remote Desktop Protocol (RDP) for Windows and Secure Shell (SSH) for UNIX are properly configured to secure data in transit when doing remote administration of systems. \n\nOrganizations should consider their out of band methods where passwords are transmitted. For example, have a:\n\n- a self serve password portal\n- telephone after positive identification of users\n- physical or in person\n\nEmail should not be used to communicated passwords.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.26,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must encrypt passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] in storage. Where passwords in storage cannot be encrypted, these passwords must not indicate the system or user ID for which they are associated.","Must",null,"Data Contributor \nIdentity Provider "]
[1.27,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must not cache unencrypted passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider "]
[1.28,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must not hard-code clear text passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] or store them in batch files.","Must",null,"Data Contributor \nIdentity Provider "]
[1.29,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that clear text passwords used to access the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] are not embedded in any automated login process, or stored in a macro or function key. Noted exceptions must be documented.","Must",null,"Data Contributor \nIdentity Provider "]
[1.3,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that all paper-based passwords used for backup or contingency purposes for their identity provider services or data contribution endpoints are stored using the principle of dual control or split knowledge.","Must",null,"Data Contributor \nIdentity Provider "]
[1.31,"Access Control and Identity Management for System Level Access Standard v1.9","In the event of an authentication failure (e.g., an invalid sign-on attempt) to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution], HICs must ensure that their identity provider services do not indicate the reason for the failure (e.g., state that it was an incorrect password or that the ID does not exist on the system).","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should ensure that general error messages are returned during authentication processes. e.g. \"Authentication Failed\".\n\nProviding information that the password or ID is incorrect gives additional information which can be used to compromise accounts.\n\nIndicating that the account is locked out is permitted.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.32,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must rename all default IDs (commonly known as vendor IDs) on their identity provider services and data contribution endpoints.","Must",null,"Data Contributor \nIdentity Provider "]
[1.33,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must change or set all default passwords on their identity provider services and data contribution endpoints, including null passwords, prior to deployment in a production environment and as soon as reasonably possible in a non-production environment.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Default and null passwords are common ways someone may try to break into a system as they may be well known and published by a vendor.  These should be changed during the build process and these steps should be included in the systems hardening procedures your organization develops.\n\nIt can be useful to build a base image with these accounts already removed to make these steps unnecessary at the Operating System level.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.34,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that VPN’s are used with additional authentication compensating factors (e.g., two-factor authentication or the use of challenge questions along with the use of VPN's) are required when accessing the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] remotely or from an untrusted source. ","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Identifying remote sysadmin users with 2 or more factors is important to keep a secured / trusted environment.   Possible mitigations are listed.\n\nHard tokens (securID)\nCall backs\nSMS messages\nRisk Based Access Control\nOne-Time Passwords\nMachine Certificates\nBio Metrics\nPersonal Certificates\n\nMany could involve an investment however it may be possible to use One-Time passwords to have sysadmins call a central helpdesk and be provided credentials once proper validation procedures are executed. ","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.35,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must prohibit remote access to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] where no additional compensating factors such as VPN, 2FA, challenge questions are provided.","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Identifying remote sysadmin users with 2 or more factors is important to keep a secured / trusted environment.   Possible mitigations are listed.\n\nHard tokens (securID)\nCall backs\nSMS messages\nRisk Based Access Control\nOne-Time Passwords\nMachine Certificates\nBio Metrics\nPersonal Certificates\n\nMany could involve an investment however it may be possible to use One-Time passwords to have sysadmins call a central helpdesk and be provided credentials once proper validation procedures are executed. ","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.36,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that session management identifiers for remote access connections to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] are unique, maintain confidentiality and integrity for each individual session, and be valid only for the duration of the current session or for a predetermined finite time period","Must","Finance","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should ensure they are using secure implementations, for example Kerberos on a Windows system. Or UNIX systems verify the  /etc./shadow.\n\nProperly configured Remote Desktop Protocol (RDP) for Windows and Secure Shell (SSH) for UNIX should be implemented for remote administration of systems.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.37,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that all users have the ability to end or terminate an active session when participating in the identity provider services and data contribution end point infrastructure participating in [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations using SSH or RDP will have the ability to terminate sessions.  Where web consoles are used these should allow termination of the session through a logout.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[1.38,"Access Control and Identity Management for System Level Access Standard v1.9","HICs must ensure that an interruption to a communication link to the identity provider services and data contribution end point infrastructure participating in [the EHR Solution] requires the person or information system to re-authenticate.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Properly configured Remote Desktop Protocol (RDP) for Windows and Secure Shell (SSH) for UNIX should be implemented for remote administration of systems which would require re-authentication if a connection is broken.","Consider Agents and ESPs with responsibilities for supporting Identity Provider and Data Contribution activities including supporting infrastructure.\n\nRefer back to the systems in scope for your organization."]
[2.1,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must clearly define and document the information security responsibilities of all their agents and Electronic Service Providers participating in [the EHR Solution].","Must",null,"Program Office"]
[2.2000000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must implement a process to verify job application information for all their new agents or Electronic Service Providers who will have access to [the EHR Solution]. Verification methods may include:\n- Character or employment references\n- Criminal record checks where possible taking into consideration employment arrangements of the organization and unions.\n- Verification of prior experience, academic record, and professional qualifications, and\n- Verification of identity from government issued identification.","Must",null,"Program Office"]
[2.2999999999999998,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that all their new agents and Electronic Service Providers who will have participating in [the EHR Solution] agree to maintain the security of information, information systems and information technologies. At a minimum, the terms and conditions of employment must:\n- Require adherence to [the EHR Solution] information security related policies\n- Explain the agent or Electronic Service Provider’s legal responsibilities and rights, e.g., regarding protection of information or privacy legislation\n- Include a non-disclosure/confidentiality clause that extends after employment; and\n- State that information security responsibilities extend outside normal working hours, premises and networks, and continue after employment has ended.","Must",null,"Program Office"]
[2.4,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must verify the identities of all persons requesting participating in [the EHR Solution]. [The EHR Solution] Program may delegate this responsibility to HICs through the use of Local Registration Authorities.","Must",null,"Program Office"]
[2.5,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that all access is provisioned based on the requestor’s established business needs, in accordance with their privacy policies, and in accordance with the principles of need-to-know and least-privilege (i.e., an agent or Electronic Service Provider is granted only the minimum access privileges required).\n\n[The EHR Solution] Program is responsible for identifying all their agents and Electronic Service Providers who require access to participate in [the EHR Solution].","Must",null,"Program Office"]
[2.6,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must implement access control systems on [the EHR Solution]. The access control system must have authentication and authorization capabilities that:\n- Identify and authenticate individual persons or information systems, and\n- Limit or restrict access to an information system’s resources, objects, data, and/or files.","Must",null,"Program Office"]
[2.7,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must assign all their agents, Electronic Service Providers, and information systems a unique ID before provisioning them with access to participate in [the EHR Solution].","Must",null,"Program Office"]
[2.8,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that access to and use of [the EHR Solution] with a user ID is traceable to a single person and that access to and use of [the EHR Solution] with a Service ID is traceable to an information system.","Must",null,"Program Office"]
[2.9,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must configure its access control and identity management system to deny access by default to [the EHR Solution] (i.e., access must be explicitly authorized).","Must",null,"Program Office"]
[2.1,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must require the creation or amendment of an ID managed by [the EHR Solution] Program to be initiated by a written or electronic request (e.g., via an email or help desk ticket) that is approved by a Sponsor unless the ID is created through an automated process (e.g., a Service ID during the installation of software). The request for ID creation must contain the access privileges requested and may contain the following information:\n- The Sponsor’s details: full name, department, sponsor authority, location, and contact information (email and telephone number (where available)), and\n- Details of whom the ID is to be assigned to: full name, department, location, and contact information (email and telephone number (where available)) or in the case of a Service ID, the details of the information system on which the ID is being created and owner\n- Justification for request (if applicable, e.g., when requesting a Privileged ID).","Must",null,"Program Office"]
[2.11,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must maintain a log of all requests for IDs that they manage and that could be used to access [the EHR Solution].","Must",null,"Program Office"]
[2.12,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must maintain a list of all IDs that have access to participate in [the EHR Solution]. The list should include the following:\n- The ID\n- Person or information system’s details: Full name, department, location, and contact information (email and telephone (where applicable))\n- Privileges associated with the ID\n- Requirement/function (for Service IDs only), and\n- Interactions (for Service IDs only).","Must",null,"Program Office"]
[2.13,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must review a list of IDs and authorizations they manage and that have access to participate in [the EHR Solution] annually to ensure that authorized access remains appropriate and must request modifications, suspensions, or revocations to privileges where inappropriate access is identified.","Must",null,"Program Office"]
[2.14,"Access Control and Identity Management for System Level Access Standard v1.9","Upon termination of employment, contractual or other relationship, or a change in job duties or responsibilities, [The EHR Solution] Program must review and if necessary request a modification, suspension or revocation of access privileges for their agents or Electronic Service Provider.","Must",null,"Program Office"]
[2.15,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must suspend user IDs that they manage and that have access to [the EHR Solution] after 180 consecutive days (or 6 months) of inactivity either manually or automatically. [The EHR Solution] Program may send the user of the ID an email warning them of the imminent suspension.","Must",null,"Program Office"]
[2.16,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must not name Privileged IDs on their information systems in a way that provides any indication of the IDs’ privilege level.","Must",null,"Program Office"]
[2.17,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must not assign privileged entitlements on their information systems or information technologies to a Personal ID. All persons requiring privileged access must be assigned a Privileged ID, and a Personal ID to be used for normal business activities.","Must",null,"Program Office"]
[2.1800000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that the assignment and use of Privileged IDs is limited to the minimum number of persons who are directly responsible for operational support or administration.","Must",null,"Program Office"]
[2.19,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that the names of their Service IDs are different than the information system names on which the Service IDs are created.","Must",null,"Program Office"]
["2,20","Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program should ensure that Service IDs are not capable of interactive sign-on.","Should",null,"Program Office"]
[2.21,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program should ensure that an identified owner is assigned to each service ID.","Should",null,"Program Office"]
[2.2200000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program may use a non-expiring password for Service IDs with credentials that are incapable of being used by a person.","Should",null,"Program Office"]
[2.23,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that a Service ID with credentials that are capable of being used by a person and are embedded into an automated process have their passwords changed to a new password either:\n- Whenever the technology changes\n- After an actual or suspected password compromise, or\n- After turnover of any person that knows the password.","Must",null,"Program Office"]
[2.2400000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must communicate initial passwords or passphrases (“passwords”) securely. Where an ID has been communicated through email, the associated password must be communicated through an alternative communication channel (e.g., via phone).","Must",null,"Program Office"]
[2.25,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must set initial passwords to prompt the user to change their password at initial login or must ensure that the user is manually instructed to change their password at initial login.","Must",null,"Program Office"]
[2.2599999999999998,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that all passwords are masked or concealed on entry, i.e., represented on the screen by a special character such as an asterisk. Temporary visibility of passwords is permitted depending on technology limitations.","Must",null,"Program Office"]
[2.27,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that their information systems are technically capable of accepting all passwords that meet the requirements and ensure compliance with the account lockout, lockout duration, history and minimum age requirements for passwords used to access [the EHR Solution]. See Appendix A.","Must",null,"Program Office"]
[2.2799999999999998,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must only reset a password after the user’s identity has been successfully verified.","Must",null,"Program Office"]
[2.2999999999999998,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must encrypt passwords in transmission.","Must",null,"Program Office"]
[2.31,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must protect passwords in storage. Where passwords stored in files cannot be encrypted, passwords must not indicate the information system or ID for which they are associated.","Must",null,"Program Office"]
[2.3199999999999998,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must not cache unencrypted passwords.","Must",null,"Program Office"]
[2.33,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must not hard-code clear text passwords into information systems or stored in batch files.","Must",null,"Program Office"]
["2,34","Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that clear text passwords are not embedded in any automated login process, or stored in a macro or function key.","Must",null,"Program Office"]
[2.35,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that all paper-based passwords used for backup or contingency purposes are stored using the principle of dual control or split knowledge.","Must",null,"Program Office"]
[2.36,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must display a terms of use banner or message at, or prior to, initial user authentication. The terms of use must be accepted by the user in order to gain participating in [the EHR Solution].","Must",null,"Program Office"]
[2.37,"Access Control and Identity Management for System Level Access Standard v1.9","In the event of an authentication failure (e.g., an invalid sign-on attempt), [the EHR Solution] Program must ensure that [the EHR Solution] does not indicate the reason for the failure (e.g., state that it was an incorrect password or that the ID does not exist on the system)","Must",null,"Program Office"]
[2.38,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must rename all default IDs (commonly known as vendor IDs).","Must",null,"Program Office"]
[2.39,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must change or set all default passwords, including null passwords, prior to deployment in a production environment and as soon as reasonably possible in a non-production environment.","Must",null,"Program Office"]
[".2.40","Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that additional authentication compensating factors (e.g., two-factor authentication or through the use of challenge questions) are required to access [the EHR Solution] remotely or from an untrusted source.","Must",null,"Program Office"]
[2.41,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that remote access for any of their users who have privileged access to participating in [the EHR Solution], directly or indirectly (e.g., through the escalation of privileges), is permitted only through the use of [the EHR Solution]-approved virtual workspace computing solution.","Must",null,"Program Office"]
[2.42,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program should maintain a record of all their agents and Electronic Service Providers that have authorized administrative remote access to participating in [the EHR Solution]. At a minimum, the record should contain:\n- The agent or Electronic Service Provider’s user ID\n- The agent or Electronic Service Provider’s full name\n- The date of creation\n- The level of entitlement granted, and\n- The full name and position of the person who authorized the request.","Must",null,"Program Office"]
[2.4300000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must employ cryptographic solutions to maintain session confidentiality and integrity of all remote access connections.","Must",null,"Program Office"]
[2.44,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that Personal IDs are not capable of establishing multiple concurrent interactive sessions to [the EHR Solution]. [The EHR Solution] Program should ensure that Privileged IDs are not capable of establishing multiple concurrent interactive sessions to [the EHR Solution].","Must",null,"Program Office"]
[2.4500000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that the state of a session is established and controlled by the information system providing the services.","Must",null,"Program Office"]
[2.46,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must implement session management mechanisms to protect session integrity and confidentiality (e.g., using Kerberos to maintain session integrity and using encryption to provide session confidentiality).","Must",null,"Program Office"]
[2.4700000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that session management identifiers are unique for each individual session, and be valid only for the duration of the current session or for a predetermined finite time period.","Must",null,"Program Office"]
[2.48,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that all users have the ability to end or terminate an active session.","Must",null,"Program Office"]
[2.4900000000000002,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that an interruption to a communication link to the source information system requires the person or information system to re-authenticate to the source information system.","Must",null,"Program Office"]
[2.5,"Access Control and Identity Management for System Level Access Standard v1.9","[The EHR Solution] Program must ensure that their workstations and other User devices that have access to participating in [the EHR Solution] either:\n- Have password-protected screen-locks, keyboard-locks or equivalent controls that are set to automatically lock after 15 minutes of inactivity\n- Set sessions to automatically terminate (e.g., sign-off active account) after a maximum period of 15 minutes of inactivity.","Must",null,"Program Office"]
[null,"Business Continuity Standard v1.7",null,null,null,"null"]
[1.1000000000000001,"Business Continuity Standard v1.7","HICs must ensure that [the EHR Solution] related identity provider services and data contribution endpoint requirements are embedded in their business continuity strategy and should address the following:\n\n- Developing a resilient technical infrastructure including disaster recovery plans,\n- Coordinating and maintaining business continuity plans and arrangements\n- Validating business continuity plans to ensure requirements can be met.","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should ensure that there is sufficient storage to queue transactions. ConnectingOntario recommends at minimum 24 hours however the maximum recovery time for a P1 incident is 72 hours.\n\nOrganizations must also ensure that the IDP logs of registration and authentication events are protected and retained.   Organizations should consider future dependence on the ConnectingOntario solution with their Clinical workflows and ensure that there are fall back procedures in the event the solution is unavailable for some time or if the IDP infrastructure the organization uses to reach ConnectingOntario is unavailable for some time.","Consider the systems in scope for the organizations participation in the EHR solution. "]
[1.2,"Business Continuity Standard v1.7","HICs should ensure that the business continuity strategy identifies the identity provider services and data contribution endpoints to be supported by business continuity plans and arrangements, and records relevant details (e.g., in a business continuity risk register) about:\n\n- The business processes they support, and\n- Key internal and external stakeholders.","Should","CISO","Data Contributor \nIdentity Provider "]
[1.3,"Business Continuity Standard v1.7","HICs should implement methods to reduce the likelihood of their identity provider services and data contribution endpoints malfunctioning, which may include:\n\n- Employing up-to-date makes/models of hardware and software that are maintained and can meet the requirements of critical business processes\n- Giving high priority to reliability, compatibility and capacity during the acquisition process\n- Ensuring compliance with common or industry security standards for hardware and software, or\n- Using telecommunication network links and services that are robust and resilient.\n","Should","CISO","Data Contributor \nIdentity Provider "]
[1.4,"Business Continuity Standard v1.7","HICs should implement methods to ensure that the availability of their identity provider services and data contribution endpoints are maintained, which may include:\n\n- Running the critical information systems simultaneously at multiple locations (e.g. by using hot stand-by or virtualization)\n- Providing alternative locations from which information systems can be run and administered, or\n- Automatically identifying and recovering transactions following an information system failure.\n","Should","CISO","Data Contributor \nIdentity Provider "]
[1.5,"Business Continuity Standard v1.7","HICs should reduce single points of failure in their network, which may include:\n\n- Rerouting network traffic automatically when critical network equipment or links fail\n- Installing duplicate or alternative network components (e.g., assets, hubs, bridges, concentrators, switches, firewalls and network traffic filters) to critical communications equipment, and\n- Arranging fall-back to alternative points of connecting and links with external service providers.","Should",null,"Data Contributor \nIdentity Provider "]
[1.6,"Business Continuity Standard v1.7","HICs should develop a method for dealing with faults on their identity provider services and data contribution endpoints, which may include:\n\n- Recording all actual or suspected faults\n- Notifying affected parties of faults in a timely manner\n- Disabling the systems and services with suspected faults until adequately remedied, and\n- Ensuring that they are repaired or replaced within critical timescales.","Should",null,"Data Contributor \nIdentity Provider "]
[1.7,"Business Continuity Standard v1.7","HICs should have a business continuity plan for each of their identity provider services or data contribution endpoints that are part of the wider business continuity strategy to support their participation in [the EHR Solution].","Should","CISO","Data Contributor \nIdentity Provider "]
[1.8,"Business Continuity Standard v1.7","HICs should appoint an owner for their identity provider services and data contribution endpoints (or group of related identity provider services and data contribution endpoints) who is responsible for developing, testing, and executing business continuity plans and arrangements for their identity provider services and data contribution endpoints.","Should",null,"Data Contributor \nIdentity Provider "]
[1.9,"Business Continuity Standard v1.7","HICs should base their business continuity plan on the results of a risk assessment, which may include:\n\n- Assessing the potential business impacts associated with the disruption of critical information systems\n- Evaluating the likelihood of critical information systems being disrupted by performing a threat risk assessment based on a set of scenarios of possible disasters or disruptions, and\n- Obtaining senior management sign-off for selective suitable business continuity plans and arrangements to treat the risks identified.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1000000000000001,"Business Continuity Standard v1.7","A HIC’s business continuity plan for their identity provider services and data contribution endpoints should include:\n\n- Conditions for their invocation\n- Arrangements for the secure storage of plans (e.g., offsite) and their retrieval in case of emergency\n- The maximum tolerable period of disruption, i.e., the maximum period of time the organization can withstand a disruption the information system(s)\n- A schedule of recovery tasks and activities to be carried out, including emergency fall back and resumption procedures (in priority order)\n- The roles and responsibilities for carrying out each task and activity\n- Information security controls to be applied following invocation of the business continuity plan (e.g., to protect the confidentiality and integrity of PHI)\n- Tasks to be undertaken following a recovery and restoration (e.g., checking that systems and information are restored to the same state they were in before the business continuity plan was invoked)\n- Ownership of the specific plan and a record of the most recent review for the adequacy of the plan, and\n- Necessary stakeholder and responsible party contact information and communications plan.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1100000000000001,"Business Continuity Standard v1.7","HICs should review and test their business continuity plans for their identity provider services and data contribution endpoints annually, which may include:\n\n- Simple tests, which involve structured walk-through tests where stakeholders meet to rehearse the business continuity plan using different scenarios\n- Medium tests, which involve simulation tests where staff test the business continuity plan using a specific scenarios and parallel tests where alternative facilities are used to avoid disrupting production information systems, or\n- Complex tests, which involve full-interruption tests where the original site is shut down and a complete test is performed at an alternative facility.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1200000000000001,"Business Continuity Standard v1.7","HICs should maintain a record of the execution of the tests with the date, the results, and sign-off from one of their senior level executive (e.g., CIO).","Should",null,"Data Contributor \nIdentity Provider "]
[2.1,"Business Continuity Standard v1.7","[The EHR Solution] Program must ensure that information security and information technology requirements are embedded in their business continuity strategy, and address the following:\n- Developing a resilient technical infrastructure including disaster recovery plans\n- Coordinating and maintaining business continuity plans and arrangements\n- Validating business continuity plans to ensure requirements can be met.","Must",null,"Program Office"]
[2.2000000000000002,"Business Continuity Standard v1.7","[The EHR Solution] Program must ensure that the business continuity strategy identifies the information systems to be supported by business continuity plans and arrangements, and records relevant details (e.g., in a business continuity risk register) about:\n- Critical information systems (ranked in order of priority) and the business processes they support, and\n- Key internal and external stakeholders.","Must",null,"Program Office"]
[2.2999999999999998,"Business Continuity Standard v1.7","[The EHR Solution] Program should ensure that [the EHR Solution] is robust, reliable and supported by alternate or duplicate facilities.","Should",null,"Program Office"]
[2.4,"Business Continuity Standard v1.7","[The EHR Solution] Program must implement methods to reduce the likelihood of critical information systems malfunctioning, which must include:\n- Employing up-to-date makes/models of hardware and software that are easily maintained and can meet the requirements of critical business processes\n- Giving high priority to reliability, compatibility and capacity during the acquisition process\n- Ensuring compliance with common or industry security standards for hardware and software, and\n- Using telecommunication network links and services that are robust and resilient.","Must",null,"Program Office"]
[2.5,"Business Continuity Standard v1.7","[The EHR Solution] Program must implement methods to ensure that the availability of critical information systems is maintained, which may include:\n- Running the critical information systems simultaneously at multiple locations (e.g. by using hot stand-by or virtualization)\n- Providing alternative locations from which information systems can be run and administered, or\n- Automatically identifying and recovering transactions following an information system failure.","Must",null,"Program Office"]
[2.6,"Business Continuity Standard v1.7","[The EHR Solution] Program must reduce single points of failure in their network, which may include:\n- Rerouting network traffic automatically when critical network equipment or links fail\n- Installing duplicate or alternative network components (e.g., assets, hubs, bridges, concentrators, switches, firewalls and network traffic filters) to critical communications equipment, or\n- Arranging fall-back to alternative points of connecting and links with external service providers.","Must",null,"Program Office"]
[2.7,"Business Continuity Standard v1.7","[The EHR Solution] Program should develop a method for dealing with faults, which may include:\n- Recording all actual or suspected faults\n- Notifying affected parties of faults in a timely manner\n- Disabling information systems and services with suspected faults until adequately remedied, and\n- Ensuring that critical information systems are repaired or replaced within critical timescales.","Should",null,"Program Office"]
[2.8,"Business Continuity Standard v1.7","[The EHR Solution] Program must ensure that a business continuity plan is created for each information system (or group of related information systems) as part of the wider business continuity strategy.","Must",null,"Program Office"]
[2.9,"Business Continuity Standard v1.7","[The EHR Solution] Program must appoint an owner for each information system (or group of related information systems) who is responsible for developing, testing, and executing business continuity plans and arrangements for their information systems.","Must",null,"Program Office"]
[2.1,"Business Continuity Standard v1.7","[The EHR Solution] Program must base the business continuity plan on the results of a risk assessment, which must include:\n- Assessing the potential business impacts associated with the disruption of critical information systems\n- Evaluating the likelihood of critical information systems being disruputed based on a set of scenarios of possible disasters or disruptions, and\n- Obtaining sign-off from a senior-level executive (e.g., a Chief Information Officer) for selective suitable business continuity plans and arrangements to treat the risks identified.","Must",null,"Program Office"]
[2.11,"Business Continuity Standard v1.7","The business continuity plan for each critical information system (or group of related critical information systems) must include:\n- Conditions for their invocation\n- Arrangements for the secure storage of plans (e.g., offsite) and their retrieval in case of emergency\n- The maximum tolerable period of disruption, i.e., the maximum period of time the organization can withstand a disruption the information system(s)\n- A schedule of recovery tasks and activities to be carried out including, emergency fall back and resumption procedures (in priority order)\n- The roles and responsibilities for carrying out each task and activity.\n- Information security controls to be applied following invocation of the business continuity plan (e.g., to protect the confidentiality and integrity of the information)\n- Tasks to be undertaken following a recovery and restoration (e.g., checking that systems and information are restored to the same state they were in before the business continuity plan was invoked)\n- Ownership of the specific plan and a record of the most recent review for the adequacy of the plan, and\n- Necessary stakeholder and responsible party contact information and communications plan.","Must",null,"Program Office"]
[2.12,"Business Continuity Standard v1.7","At a minimum, [the EHR Solution] Program must review and test their business continuity plans annually, which must include at least one of the following, with each scenario being tested within a period of three years:\n- Simple tests, which involve structured walk-through tests where stakeholders meet to rehearse the business continuity plan using different scenarios\n- Medium tests, which involve simulation tests where staff test the business continuity plan using a specific scenarios and parallel tests where alternative facilities are used to avoid disrupting production information systems, or\n- Complex tests, which involve full-interruption tests where the original site is shut down and a complete test is performed at an alternative facility","Must",null,"Program Office"]
[2.13,"Business Continuity Standard v1.7","[The EHR Solution] Program must maintain a record of the execution of the tests with the date, the results, and sign-off from a senior level executive (e.g., CIO).","Must",null,"Program Office"]
[null,"Cryptography Standard v1.8",null,null,null,"null"]
[1.1000000000000001,"Cryptography Standard v1.8","HICs must only use [the EHR Solution]-approved cryptographic algorithms to participate in [the EHR Solution]. A list of approved cryptographic algorithms can be found in Appendix A: Approved Cryptographic Algorithms.","Must","CISO","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Review the various implementations of encryption in your organization.   This will involve having your technical representatives accessing the various systems and verifying the cryptography implementation.  Direction can be taken from the appendix in the cryptography policy as to what algorithms are acceptable. \n\nWhere an algorithm is not compliant, consider what effort would be required to enhance the cryptography. This may involve a software update, configuration change or potentially a replacement of hardware.\n\nNote the certificates issued to the data contribution and identity provider infrastructure from eHealth Ontario are configured with 1024 bit key lengths and SHA1 which do not meet the policy. A project is underway to update the certificate issuing system and updated certificates will be deployed to sites as they come due for renewal.\n\nBy design, the connecting between your HIC-approved device and the EHR Solution will leverage a cryptographic connection that meets the policy requirement.","Consider the systems in scope for the organizations participation in the EHR solution.  Considerations include but are not limited to:\n\nViewers: \nHard drive encryption\nRemote access VPN\nWireless networks\n\nIDP / DC:\nPassword Files \nWeb Console for DC or IDP systems, including account management \nDC / IDP connections to eHealth Ontario\nHard drive encryption\nRemote access VPN\nWireless networks"]
[1.2,"Cryptography Standard v1.8","HICs must assess each proposed implementation of a cryptographic solution on their identity provider services and data contribution endpoints. ","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Review the various implementations of encryption in your organization.   This will involve having your technical representatives accessing the various systems and verifying the cryptography implementation.  Direction can be taken from the appendix in the cryptography policy as to what algorithms are acceptable. \n\nWhere an algorithm is not compliant, consider what effort would be required to enhance the cryptography. This may involve a software update, configuration change or potentially a replacement of hardware.\n\nNote the certificates issued to the data contribution and identity provider infrastructure from eHealth Ontario are configured with 1024 bit key lengths and SHA1 which do not meet the policy. A project is underway to update the certificate issuing system and updated certificates will be deployed to sites as they come due for renewal.","Consider the systems in scope for the organizations participation in the EHR solution.  Considerations include but are not limited to:\n\nViewers: \nHard drive encryption\nRemote access VPN\nWireless networks\n\nIDP / DC:\nPassword Files \nWeb Console for DC or IDP systems, including account management \nDC / IDP connections to eHealth Ontario\nHard drive encryption\nRemote access VPN\nWireless networks"]
[1.3,"Cryptography Standard v1.8","HICs must ensure that cryptographic solutions on their identity provider services and data contribution endpoints fail close (i.e., access is denied if a failure occurs).","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Most cryptography implementation will fail closed meaning that the connectivity will not occur if the connection cannot be established securely.\n\nOrganizations should consider some recent vulnerabilities including POODLE (padding oracle on downgraded legacy encryption), this allowed an attacker to downgrade the encryption from a secure connection to a less secure connection by causing handshake failures. Patches and configurations can be used to protect against these exposures.","Consider the implementations define in your organizations scope from section 1.1."]
[1.4,"Cryptography Standard v1.8","HICs should use hardware cryptography (rather than software cryptography) for their identity provider services and data contribution endpoints.","Should",null,"Data Contributor \nIdentity Provider "]
[1.5,"Cryptography Standard v1.8","Where cryptographic hardware devices are (e.g. RSA Token)  used for their identity provider services and data contribution endpoints, HICs must ensure that the cryptographic hardware devices meet or exceed the tamper-resistant enclosure requirements specified in the Federal Information Processing Standards (FIPS) 140-3 standard. ","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Consider if your organization uses hardware based cryptography.  If so, reach out to the vendor to determine if your device is FIPS-140-2 Level 3 compliance.\n\nIf not FIPS-140-2 level 3 compliant, consider compensating controls such as adequate physical security on the devices and in server rooms.","Consider the implementations define in your organizations scope from section 1.1."]
[1.6,"Cryptography Standard v1.8","HICs should only use software cryptography solutions on their identity provider services and data contribution endpoints for:\n\n- One-way (or non-reversible) cryptographic functions\n- Client-side software for remote access\n- Client-side storage encryption such as full-disk encryption, or\n- Client-side or server-side digital certificates.","Should",null,"Data Contributor \nIdentity Provider "]
[1.7,"Cryptography Standard v1.8","Where a software-based cryptography is implemented, HICs must ensure that the password is not stored in a program, batch file, or script file, with the exception of server-based SSL digital certificates, which must have strict access control placed on the file that contains the password.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Consider if your organization includes passwords to crypto components in batch files or clear text.  Often these may be used in the data contribution interface configuration files to bind the application to the cryptography key.\n\nMany application development frameworks would have the capability to encrypt these configuration files so that they are not accessible. (e.g. .NET FRAMEWORK)","Consider the implementations define in your organizations scope from section 1.1."]
[1.8,"Cryptography Standard v1.8","HICs must ensure that all digital certificates are revocable with a cryptographically secured certificate revocation list (CRL) system.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"The IDP / DC connection to eHealth Ontario is established through the ONE ID Certificate Authority which provides a mechanism to call the CRL to see if the certificate has been revoked.\n\nWhere a HIC may have a web interface to call a LRA portal or their HIS system, that cryptography is implemented locally. Organizations can purchase a certificate from a public Certificate Authority such as Verisign, GoDaddy, GeoTrust, etc. Those Certificate Authorities would offer a CRL for the Client browsers to verify that the connection could be trusted.    If self signed certificates are implemented then there is typically not a CRL list.   An organization should look to add the self signed certificate to the Browsers of its clients to avoid the common error \"There is a problem with the website's certificate\" (Continue to this website (not recommended)) which reduces Client confidence,  and may lead the user to divulge their password to an untrusted site.","Consider the implementations define in your organizations scope from section 1.1."]
[1.9,"Cryptography Standard v1.8","HICs must ensure that a digital certificate is only trusted once it has been cryptographically validated and does not appear on a trusted CRL.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"The IDP / DC connection to eHealth Ontario is established through the ONE ID Certificate Authority which provides a mechanism to call the CRL to see if the certificate has been revoked.\n\nWhere a HIC may have a web interface to call a LRA portal or their HIS system, that cryptography is implemented locally. Organizations can purchase a certificate from a public Certificate Authority such as Verisign, GoDaddy, GeoTrust, etc. Those Certificate Authorities would offer a CRL for the Client browsers to verify that the connection could be trusted.    If self signed certificates are implemented then there is typically not a CRL list.   An organization should look to add the self signed certificate to the Browsers of its clients to avoid the common error \"There is a problem with the website's certificate\" (Continue to this website (not recommended)) which reduces Client confidence,  and may lead the user to divulge their password to an untrusted site.","Consider the implementations define in your organizations scope from section 1.1."]
[1.1000000000000001,"Cryptography Standard v1.8","HICs must protect their cryptographic keys for their identity provider services and data contribution endpoints against unauthorized access (in the case of secret and private keys), modification, loss, and accidental or intentional destruction.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations need to consider how they are protecting the keys that are used. Controls to implement may include:\n\n- Proper access controls to minimize access to those that need it.\n- Using strong passwords to protect Private Keys stored in built in operating system certificate stores\n- Minimize the need to duplicate keys","Consider the implementations define in your organizations scope from section 1.1."]
[1.1100000000000001,"Cryptography Standard v1.8","HICs must ensure that equipment used to generate, load, store and archive cryptographic keys for their identity provider services and data contribution endpoints are physically protected against unauthorized access or modification.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should generate, load, store keys on the systems where they will be used so that duplicate copied can be avoided.  Controls should be implemented to protect the keys while stored on those systems.","Consider the implementations define in your organizations scope from section 1.1."]
[1.1200000000000001,"Cryptography Standard v1.8","HICs should establish a process for managing cryptographic keys for their identity provider services and data contribution endpoints, which covers:\n\n- The secure generation, distribution, loading, storage, recovery, replacement, revocation and destruction of cryptographic keys, and\n- The secure back-up and archive of cryptographic keys. ","Should",null,"Data Contributor \nIdentity Provider "]
[1.1299999999999999,"Cryptography Standard v1.8","HICs must maintain an inventory of their cryptographic keys and key components associated with their identity provider services and data contribution endpoints. The inventory should contain the following:\n\n- Key name and purpose/usage\n- Key type\n- Key generation date\n- Component number, including the total number of components\n- Storage location(s)\n- All key custodians since generation, including the dates of custodial changes, and\n- Date the key was destroyed, and proof of destruction.\n","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations may develop a spreadsheet that includes the attributes required.","Consider the implementations define in your organizations scope from section 1.1."]
[1.1399999999999999,"Cryptography Standard v1.8","HICs should review the inventory of keys associated with their identity provider services and data contribution endpoints annually.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1499999999999999,"Cryptography Standard v1.8","HICs should maintain logs to record any instance in which keys, key components, or related materials for their identity provider services and data contribution endpoints are generated, removed from storage or loaded to a cryptographic device.  Logs may include:\n\n- Key name and purpose/usage\n- Date and time\n- Component identifier\n- Purpose of access\n- Name and signature of custodian accessing the component, and\n- Tamper evident package number pre and prior to removal (if applicable). ","Should",null,"Data Contributor \nIdentity Provider "]
[1.1599999999999999,"Cryptography Standard v1.8","HICs must restrict access to cryptographic keys or key components, and key devices for their identity provider services and data contribution endpoints to the designated key custodians and their backups.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations need to consider how they are protecting the keys that are used. Controls to implement may include:\n\n- Proper access controls to minimize access to those that need it.\n- Using strong passwords to protect Private Keys stored in built in operating system certificate stores\n- Minimize the need to duplicate keys","Consider the implementations define in your organizations scope from section 1.1."]
[1.17,"Cryptography Standard v1.8","HICs should store keys for their identity provider services and data contribution endpoints in the fewest possible locations and forms. ","Should",null,"Data Contributor \nIdentity Provider "]
[1.18,"Cryptography Standard v1.8","HICs must ensure that all keys and key components for their identity provider services and data contribution endpoints are generated using a random number generator or a pseudo-random number generator that passes all the basic tests for statistical randomness as defined in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-22 Revision 1a.","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations using automatic password generators should ensure that the obligations of this control are met.\n\nWhere an organization generates passwords then these should follow the password requirements in the Access Control standard.\n\nUsing passwords that meet the requirements of the Access Control policy will suffice for keys. ","Consider the implementations define in your organizations scope from section 1.1."]
[1.19,"Cryptography Standard v1.8","To ensure the confidentiality of secret keys for their identity provider services and data contribution endpoints, HICs must ensure that secret keys only exists in the following forms: \n\n- As cleartext inside the protected memory of a tamper-resistant security module (TRSM) \n- As cyphertext outside the protected memory of a TRSM, or \n- As two or more components, held under split knowledge and dual control. ","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should review their crypto implementation to ensure that private keys and passwords are not executing in plain text.\n\nWhere keys are held offline, those should have split knowledge or managed to verify use.","Consider the implementations define in your organizations scope from section 1.1."]
[1.2,"Cryptography Standard v1.8","HICs should require the output of the key generation process for their identity provider services and data contribution endpoints to be monitored by at least two authorized agents or Electronic Service Providers.","Should",null,"Data Contributor \nIdentity Provider "]
[1.21,"Cryptography Standard v1.8","HICs must ensure that multi-use or multi-purpose computing systems are not used for key generation where any clear-text secret key or key component may appear in unprotected memory.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should generate, load, store keys on the systems where they will be used so that duplicate copied can be avoided.  Controls should be implemented to protect the keys while stored on those systems.","Consider the implementations define in your organizations scope from section 1.1."]
[1.22,"Cryptography Standard v1.8","HICs must ensure that keys or key components for identity provider services and data contribution endpoints are never loaded (or reloaded) when there is any suspicion that either the key, key components or the cryptographic device has been compromised. ","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should integrate this process into their incident management and cryptography controls. In the event a key has been or is suspected of compromise. The organization should contact eHealth Ontario as per the incident management process and request that a new certificate is generated.  The old certificate should be deleted, eHealth Ontario will put the old certificate on the Certificate Revocation List.\n\nA similar process should be put in place for public Certificate Authority certificates purchased by the organization.  (e.g. on VPN or Web Consoles)  eHealth Ontario is not involved in these certificates.","Consider the implementations define in your organizations scope from section 1.1."]
[1.23,"Cryptography Standard v1.8","HICs must only use cryptographic keys on their identity provider services and data contribution endpoints for a single intended purpose and must never share these keys between production and non-production environments. ","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"eHealth Ontario will provide separate certificates to the organization for data contribution and identity provider activities as well as separate certificates for conformance test, clinical validation and production environments.\n\nOrganizations should ensure these are generated and loaded on separate systems. The locations (systems) should be recorded in the certificate inventory spreadsheet.\n\nSeparate certificates will help prevent situations where test and production data could be sent to incorrect environments.","Consider the implementations define in your organizations scope from section 1.1."]
[1.24,"Cryptography Standard v1.8","A certificate key lifespan must be no longer than 7 years.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"The certificates issued by eHealth Ontario will be valid for a period of 3 years and will be refreshed prior to coming due.  \n\nAs of April 1, 2015, Certificate Authorities will no longer be able to issue certificates for a lifetime longer than 39 months. (3.25 years).\n\nOrganizations should review public CA certificates to validate the start and expiration date.  Certificates issued from eHealth Ontario can be assumed to be compliant.","Consider the implementations define in your organizations scope from section 1.1."]
[1.25,"Cryptography Standard v1.8","HICs must replace an uncompromised key used for their identity provider services and data contribution endpoints on or before its stipulated lifespan.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"The max certificate lifespan in the EHR Security Policy is 7 years.  Certificates that are older than 7 years must be replaced.  Typically certificates that are more than 7 years old would be leveraging older cryptography algorithms and it would be prudent to replace the certificates to ensure they were compliant with the policy.","Consider the implementations define in your organizations scope from section 1.1."]
[1.26,"Cryptography Standard v1.8","If a key or key component for a HIC’s identity provider services and data contribution endpoints has been compromised or is suspected of being compromised, the HIC must: \n\n- Replace the compromised or suspected compromised key as soon as possible. The replacement key must not be a variant of the original key\n- Inspect the cryptographic device for any form of unauthorized modification before installing the new key or key component. ","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should integrate this process into their incident management and cryptography controls. In the event a key has been or is suspected of compromise. The organization should contact eHealth Ontario as per the incident management process and request that a new certificate is generated.  The old certificate should be deleted, eHealth Ontario will put the old certificate on the Certificate Revocation List.\n\nA similar process should be put in place for public Certificate Authority certificates purchased by the organization.  (e.g. on VPN or Web Consoles)  eHealth Ontario is not involved in these certificates.","Consider the implementations define in your organizations scope from section 1.1."]
[1.27,"Cryptography Standard v1.8","HICs must promptly revoke all keys or key components for their identity provider services and data contribution endpoints when no longer required and ensure that the key or key components are securely destroyed.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should ensure decommissioning procedures or projects include these obligations. Certificates should be revoked and put on a CRL, if certificates are used for authentication then mapping tables should be revoked to removed access.\n\nOrganizations should call eHealth Ontario if the certificate that was issued to them needs to be added to the CRL.","Consider the implementations define in your organizations scope from section 1.1."]
[1.28,"Cryptography Standard v1.8","HICs should require the destruction of their keys or key components for their identity provider services and data contribution endpoints to be witnessed by the key custodians and the details of the destruction recorded for audit purposes. The record may include:\n\n- The date and time of the keying material destruction \n- The reason for destroying the keying material\n - The full name and signature of the individual authorizing the destruction\n - The full name and signature of the individual destroying the keying material, and\n- The full name and signature of all persons witnessing the destruction.","Should",null,"Data Contributor \nIdentity Provider "]
[1.29,"Cryptography Standard v1.8","The Chief Information Officer or their delegate must assign the Key Custodian(s) responsible for each key.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"The organization should assign a key custodian(s) for each key. This should be recorded in the cryptography inventory.","Consider the implementations define in your organizations scope from section 1.1."]
[1.3,"Cryptography Standard v1.8","HICs must ensure that key custodians for their identity provider services and data contribution endpoints handle the key or key component in their custody in a Restricted manner as described in the Information and Asset Management Policy. ","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"When developing the key handling procedures, organizations should review the Information Asset Management Policy and ensure that the procedures map to the control requirements. \n\nCryptographic keys and passwords are classified as \"Restricted\" in the Policy.  See appendices.  Consider these when developing your procedures in control 1.15","Consider the implementations define in your organizations scope from section 1.1."]
[1.31,"Cryptography Standard v1.8","HICs must ensure that each cryptographic key or key component has the fewest number of key custodians necessary. ","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Organizations need to consider how they are protecting the keys that are used. Controls to implement may include:\n\n- Proper access controls to minimize access to those that need it.\n- Using strong passwords to protect Private Keys stored in built in operating system certificate stores\n- Minimize the need to duplicate keys\n\nConsider these controls with 1.20","Consider the implementations define in your organizations scope from section 1.1."]
[1.32,"Cryptography Standard v1.8","HICs must ensure that key custodians understand their responsibility to never disclose the key or key component in their custody to anyone, not even to a manager or an auditor, except to another authorize key custodian for that specific key or key component.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Include this requirement in an Acceptable Use or Cryptography  policy / practices.  Messages can be communicated through training.","Consider the implementations define in your organizations scope from section 1.1."]
[2.1,"Cryptography Standard v1.8","Only [the EHR Solution]-approved cryptographic algorithms shall be implemented on [the EHR Solution]. A list of approved cryptographic algorithms can be found in Appendix A: Approved Cryptographic Algorithms","Must",null,"Program Office"]
[2.2000000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that each proposed implementation of a cryptographic solution on [the EHR Solution] is assessed by an information security specialist.","Must",null,"Program Office"]
[2.2999999999999998,"Cryptography Standard v1.8","[The EHR Solution] Program must only implement cryptographic solutions that fail close (i.e., access is denied if a failure occurs).","Must",null,"Program Office"]
[2.4,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that all implementations of cryptography have documented contingency procedures prior to production implementation. These procedures must be made available to all relevant stakeholders.","Must",null,"Program Office"]
[2.5,"Cryptography Standard v1.8","[The EHR Solution] Program should use hardware cryptography ( example: RSA Token)(rather than software cryptography) in environments that store or process PHI.","Should",null,"Program Office"]
[2.6,"Cryptography Standard v1.8","Where cryptographic hardware devices are used, [the EHR Solution] Program must ensure that these devices meet or exceed the tamper-resistant enclosure requirements specified in the Federal Information Processing Standards (FIPS) 140-3 standard.","Must",null,"Program Office"]
[2.7,"Cryptography Standard v1.8","[The EHR Solution] Program must only permit software cryptography solution to only be permitted for:\n- One-way (or non-reversible) cryptographic functions\n- Client-side software for remote access\n- Client-side storage encryption such as full-disk encryption\n- Client-side or server-side digital certificates, or\n- Data storage in data centres.","Must",null,"Program Office"]
[2.8,"Cryptography Standard v1.8","Where a software-based cryptography is implemented, [the EHR Solution] Program must ensure that the password is not be stored in a program, batch file, or script file, with the exception of server-based SSL digital certificates, which must have strict access control placed on the file that contains the password.","Must",null,"Program Office"]
[2.9,"Cryptography Standard v1.8","[The EHR Solution] Program must cryptographically protect the integrity of their cryptographic keys, especially when their cryptographic keys are located in a publicly accessible location (e.g., Internet-facing web server).","Must",null,"Program Office"]
[2.1,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that all digital certificates are revocable.","Must",null,"Program Office"]
[2.11,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that a digital certificate is only trusted once it has been cryptographically validated and does not appear on a trusted CRL.","Must",null,"Program Office"]
[2.12,"Cryptography Standard v1.8","[The EHR Solution] Program must protect their cryptographic keys against unauthorized access (in the case of secret and private keys), modification, loss, and accidental or intentional destruction.","Must",null,"Program Office"]
[2.13,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that equipment used to generate, load, store and archive cryptographic keys are physically protected against unauthorized access or modification.","Must",null,"Program Office"]
[2.14,"Cryptography Standard v1.8","[The EHR Solution] Program must establish a process for managing cryptographic keys, which covers:\n- The secure generation, distribution, loading, storage, recovery, replacement, revocation and destruction of cryptographic keys, and\n- The secure back-up and archive of cryptographic keys.\nThese processes and procedures must be made available to all relevant stakeholders. \n","Must",null,"Program Office"]
[2.15,"Cryptography Standard v1.8","[The EHR Solution] Program must maintain an inventory for all their cryptographic keys and key components. The inventory should include the following:\n- Key name and purpose/usage\n- Key type\n- Key generation date\n- Component number, including the total number of components\n- Storage location(s)\n- All key custodians since generation, including the dates of custodial changes, and\n- Date the key was destroyed, and proof of destruction.\n","Must",null,"Program Office"]
[2.16,"Cryptography Standard v1.8","[The EHR Solution] Program should review the inventory of their cryptographic keys annually.","Should",null,"Program Office"]
[2.17,"Cryptography Standard v1.8","[The EHR Solution] Program must maintain logs to record any instance in which keys, key components, or related materials are generated, removed from storage or loaded to a cryptographic device. The logs should include:\n- Key name and purpose/usage\n- Date and time\n- Component identifier\n- Purpose of access\n- Name and signature of custodian accessing the component, and\n- Tamper evident package number pre and prior to removal (if applicable).","Must",null,"Program Office"]
[2.1800000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program should review the audit logs of their keys annually.","Should",null,"Program Office"]
[2.19,"Cryptography Standard v1.8","[The EHR Solution] Program must restrict access to secret keys or key components, key devices and key materials to key custodians and their backups. Generally, the designation of a primary and a backup key custodian for each key or key component is sufficient.","Must",null,"Program Office"]
[2.2000000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program must store keys in the fewest possible locations and forms.","Must",null,"Program Office"]
[2.21,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that backup copies of secret keys exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one of the allowed storage forms for that key.","Must",null,"Program Office"]
[2.2200000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that the backup copies of secret keys are stored with strict access controls, under dual control, and subject to at least the same level of control as operational keys.","Must",null,"Program Office"]
[2.23,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that the creation of backup copies (including cloning) require at least two authorized persons to enable the process. All requirements applicable for the original keys must also apply to any backup copies of keys and their components.","Must",null,"Program Office"]
[2.2400000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that secret keys and key components that are no longer used or have been replaced are securely revoked and destroyed.","Must",null,"Program Office"]
[2.25,"Cryptography Standard v1.8","[The EHR Solution] Program must only permit a key generation process to be initiated by the key custodian.","Must",null,"Program Office"]
[2.2599999999999998,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that all keys and key components are generated using a random number generator or a pseudo-random number generator that passes all the basic tests for statistical randomness as defined in the NIST Special Publication (SP) 800-22 Revision 1a.","Must",null,"Program Office"]
[2.27,"Cryptography Standard v1.8","To ensure the confidentiality of their secret keys, [the EHR Solution] Program must ensure that a secret key only exists in the following forms:\n- As cleartext inside the protected memory of a tamper-resistant security module (TRSM)\n- As cyphertext outside the protected memory of a TRSM, or\n- As two or more components, held under split knowledge and dual control.","Must",null,"Program Office"]
[2.2799999999999998,"Cryptography Standard v1.8","[The EHR Solution] Program should ensure that the output of the key generation process is monitored by at least two authorized agents or Electronic Service Providers.","Should",null,"Program Office"]
[2.29,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that multi-use or multi-purpose computing systems are not used for key generation where any clear-text secret key or key component thereof appears in unprotected memory.","Must",null,"Program Office"]
[2.2999999999999998,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that a key encryption key (KEK) is transferred by physically forwarding the separate components of the key using different communication channels or is transmitted electronically in cipher-text form.","Must",null,"Program Office"]
[2.31,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that any sign of package tampering results in the destruction and replacement of the set of key components, as well as any keys encrypted under this (combined) key.","Must",null,"Program Office"]
[2.3199999999999998,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that mechanisms exist to ensure that only authorized key custodians place key components into tamper-evident packaging for transmittal and that only authorized key custodians open tamper-evident packaging containing key components upon receipt.","Must",null,"Program Office"]
[2.33,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that keys or key components are never loaded (or reloaded) when there is any suspicion that either the key, key components or the cryptographic device has been compromised.","Must",null,"Program Office"]
[2.34,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that unencrypted secret keys are entered into cryptographic devices using the principles of dual control and split knowledge. In instances where a secure key loading device is used, only dual control is required.","Must",null,"Program Office"]
[2.35,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that any hardware used in the key-loading function are controlled and maintained in a secure environment under dual control.","Must",null,"Program Office"]
[2.36,"Cryptography Standard v1.8","[The EHR Solution] Program should require key custodians to examine all cable attachments before each key loading activity to ensure they have not been tampered with or compromised.","Should",null,"Program Office"]
[2.37,"Cryptography Standard v1.8","[The EHR Solution] Program must define and implement procedures to prevent or detect the unauthorized substitution (unauthorized key replacement and key misuse) of one key or key component for another, or the operation of any cryptographic device without legitimate keys or key components.","Must",null,"Program Office"]
[2.38,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that cryptographic keys are only used for a single intended purpose and must never be shared between production and non-production environments.","Must",null,"Program Office"]
[2.39,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that all secret keys used for any function are unique (except by chance) to that device.","Must",null,"Program Office"]
[2.4,"Cryptography Standard v1.8","A certificate key lifespan must be no longer than 7 years.","Must",null,"Program Office"]
[2.41,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that an uncompromised key is replaced on or before its stipulated lifespan.","Must",null,"Program Office"]
[2.42,"Cryptography Standard v1.8","If a key or key component has been compromised or is suspected of being compromised, [the EHR Solution] Program must:\n- Replace the compromised or suspected compromised key as soon as possible. The replacement key must not be a variant of the original key.\n- Inspect the cryptographic device for any form of unauthorized modification before installing the new key or key component.","Must",null,"Program Office"]
[2.4300000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that their keys are promptly revoked when no longer required and ensure that the key is destroyed in accordance with [the EHR Solution] Information and Asset Management Policy.","Must",null,"Program Office"]
[2.44,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that the destruction of a key is witnessed by the key custodians with the appropriate records retained for audit purposes. Each key or key component destruction should record the following:\n- The date and time of the keying material destruction\n- The reason for destroying the keying material\n- The full name and signature of the individual authorizing the destruction\n- The full name and signature of the individual destroying the keying material, and\n- The full name and signature of the persons witnessing the destruction.","Must",null,"Program Office"]
[2.4500000000000002,"Cryptography Standard v1.8","The Chief Information Officer or their delegate must assign the Key Custodian(s) responsible for each key.","Must",null,"Program Office"]
[2.46,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that Key Custodians handle the key or key component in their custody in a Restricted manner as described in the Information and Asset Management Policy.","Must",null,"Program Office"]
[2.4700000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that Key Custodians assigned to cryptographic keys are limited to the fewest number of key custodians necessary.","Must",null,"Program Office"]
[2.48,"Cryptography Standard v1.8","[The EHR Solution] Program must ensure that Key Custodians understand their responsibility to never disclose the key in their custody to anyone, not even to a manager or an auditor, except to another authorized Key Custodian for that specific key.","Must",null,"Program Office"]
[2.4900000000000002,"Cryptography Standard v1.8","[The EHR Solution] Program must never permit a Key Custodian to be the custodian for more than one key component for the same key, even if the custodianship applies to the key components at different times.","Must",null,"Program Office"]
[null,"Electronic Service Provider Standard v1.8",null,null,null,"null"]
[1.1000000000000001,"Electronic Service Provider Standard v1.8","HICs should identify Electronic Service Providers and categorize them according to supplier type (e.g., application service provider, network service provider, storage service provider, etc.) and criticality of the services they provide. ","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Identify and document the Electronic Service Provider relationships your organization has entered. Document the type of service performed and their criticality of the service to your business operations. \n\nKeep these records with your Office Manager or accountable party.","Scope may include but not limited to:\n\nESP who may provide Local Desktop / Laptop and Device support\nESP support for HIS / Integration Point Support\nESP support for IDP systems\nESP relied on for shared services\nESP relied on for remote connectivity\nESP relied on for network connectivity"]
[1.2,"Electronic Service Provider Standard v1.8","HICs must assess the potential information security and privacy risks posed by all new Electronic Service Providers to [the EHR Solution] prior to engaging in a contractual relationship with that Electronic Service Provider.  ","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Review ESP relationships that support the organizations participation in the EHR solution. \n\nPerform a risk assessment based on the services that they provide.  Consider the Asset sensitivity for the services the ESP provide (L, M, H) and then consider threats and impacts to those services to determine risk.","Scope may include but not limited to:\n\nESP who may provide Local Desktop / Laptop and Device support\nESP support for HIS / Integration Point Support\nESP support for IDP systems\nESP relied on for shared services\nESP relied on for remote connectivity\nESP relied on for network connectivity"]
[1.3,"Electronic Service Provider Standard v1.8","HICs must define and document all information systems and services to be provided by new Electronic Service Providers or on renewal of service agreements. Service agreements should specify:\n\n- Roles and responsibilities under PHIPA and under the privacy and information security policies and procedures implemented in respect to [the EHR Solution]\n- Roles and responsibilities for implementing, maintaining and supporting the information systems or services to be provided\n- The level of criticality of the service\n- The dates and times when the service is required\n- The capacity requirements of systems and networks\n- Maximum permissible down-time and service level objectives\n- Service level reports and frequency\n- Critical timescales, i.e., the timescale beyond which a loss of service would be unacceptable to the HIC\n- The penalties to be imposed in the event the Electronic Service Provider fails to deliver the pre-agreed level of service or fails to fulfill its roles and responsibilities, and \n- Minimum information security and privacy controls.\n- 1.3.11. Expected deliverables \n- Representatives of Electronic Service Providers.\n","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Document the ESP relationships.  Procurement or vendor offices may have this information.\n\nRequire future contracts to reference the EHR Policies.","Scope may include but not limited to:\n\nESP who may provide Local Desktop / Laptop and Device support\nESP support for HIS / Integration Point Support\nESP support for IDP systems\nESP relied on for shared services\nESP relied on for remote connectivity\nESP relied on for network connectivity"]
[1.4,"Electronic Service Provider Standard v1.8","HICs must require new Electronic Service Providers to implement applicable information security and privacy controls as outlined in the EHR policy and standard prior to the Electronic Service Provider being granted access or providing support to [the EHR Solution].","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Require that the ESPs relied on for interaction with the EHR Solution have been communicated their Privacy and Security obligations.\n\nRequire relevant ESP to take the training courses that were developed.","Scope may include but not limited to:\n\nESP who may provide Local Desktop / Laptop and Device support\nESP support for HIS / Integration Point Support\nESP support for IDP systems\nESP relied on for shared services\nESP relied on for remote connectivity\nESP relied on for network connectivity"]
[1.5,"Electronic Service Provider Standard v1.8","HICs should establish a consistent method for handling the termination of relationships with Electronic Service Providers, which may include:\n\n- Designating agents responsible for managing the termination\n- Revocation of physical and logical access rights to the organization’s information, and \n- Secure return, transfer or destruction of all assets (e.g. back-up media storage, documentation, hardware, and authentication devices).\n","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Ensure responsibilities are assigned to an individual who will terminate ESP relationships.  Ensure access rights are revoked for the ESP, ensure that relevant assets are returned.","Scope may include but not limited to:\n\nESP who may provide Local Desktop / Laptop and Device support\nESP support for HIS / Integration Point Support\nESP support for IDP systems\nESP relied on for shared services\nESP relied on for remote connectivity\nESP relied on for network connectivity"]
[2.1,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program should identify Electronic Service Providers and categorize them according to supplier type (e.g., application service provider, network service provider, storage service provider, etc.) and criticality of the services they provide.","Should",null,"Program Office"]
[2.2000000000000002,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program must assess the potential information security and privacy risks posed by Electronic Service Providers to [the EHR Solution] prior to engaging in a contractual relationship with that Electronic Service Provider.","Must",null,"Program Office"]
[2.2999999999999998,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program must define and document all information systems and services to be provided by any new Electronic Service Provider or on renewal of any service agreements. At a minimum, service agreements must specify:\n- Roles and responsibilities under PHIPA and under the privacy and information security policies and procedures implemented in respect of [the EHR Solution]\n- Roles and responsibilities for implementing, maintaining and supporting the information systems or services to be provided\n- The level of criticality of the service\n- The dates and times when the service is required\n- The capacity requirements of systems and networks\n- Maximum permissible down-time and service level objectives\n- Service level reports and frequency\n- Critical timescales, i.e., the timescale beyond which a loss of service would be unacceptable to [the EHR Solution]\n- The penalties to be imposed in the event the Electronic Service Provider fails to deliver the pre-agreed level of service or fails to fulfill its roles and responsibilities, and\n- Minimum information security and privacy controls.\n- Expected deliverables \n- Representatives of Electronic Service Providers.\n","Must",null,"Program Office"]
[2.4,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program must require Electronic Service Providers to implement all applicable information security and privacy controls prior to the Electronic Service Provider being granted access to [the EHR Solution].","Must",null,"Program Office"]
[2.5,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program must ensure that threat risk assessments are performed on their Electronic Service Providers.","Must",null,"Program Office"]
[2.6,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program must give consideration to restricting the location of information, information processing, and information system services controlled or provided by Electronic Service Providers (e.g., an organization may choose to prohibit an Electronic Service Provider from storing their information on servers located outside of Canada).","Must",null,"Program Office"]
[2.7,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program should establish a consistent method for handling the termination of Electronic Service Provider relationships, which should include:\n- Designating agents responsible for managing the termination;\n- Revocation of physical and logical access rights to the organization’s information; and\n- Secure return, transfer or destruction of all assets (e.g. back-up media storage, documentation, hardware, and authentication devices).","Must",null,"Program Office"]
[2.8,"Electronic Service Provider Standard v1.8","[The EHR Solution] Program must establish contingency arrangements to ensure that their respective business processes can continue in the event that the Electronic Service Provider is not available (e.g., due to contract termination, a disaster, or labour disputes). These arrangements should be based on the results of a threat risk assessment, and may include:\n- The provision of alternative, secure facilities for business processes to continue\n- Escrow of information and close/propriety technologies (e.g., application source code and cryptographic keys using a trusted external party, such as a lawyer.\n- Recovery arrangements to ensure continued availability of information stored at an outsource provider or in the cloud, or\n- Alignment with [the EHR Solution] business continuity program.","Must",null,"Program Office"]
[null,"Information Asset Management Standard v1.8",null,null,null,"null"]
[1.1000000000000001,"Information Asset Management Standard v1.8","HICs must ensure that all PHI that is transmitted to [the EHR Solution] Program Office or [the EHR Solution] is done in a secure manner, e.g., through the use of secure email, encryption, or virtual private network tunnel.\n\nSee appendix A and B.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Data Contribution and Identity Provider transmission include security requirements in the interface specification.  Passing the testing cycles will suffice to meet the requirement.\n\nOut of band transfers may be required through email during troubleshooting or an incident.  The organization must have ONE Mail or include encryption of the data in transit. ONE Mail is acceptable as a method to communicate PHI however this information must not be communicated to the Program Office Service Desk.  If ONE Mail is not used then encryption should be applied to the data in transit, either through a strong password in a MS Office document or with WinZip. See password requirements in this Policy and ensure that the password is communicated in an out of band method (i.e. telephone).","Consider situations where PHI is transmitted to the EHR Solution Program Office. This may include:\n\nData Contribution to the solution  - security requirements are included in the interface specification. Passing testing will suffice.\n\nIdentity Provider assertions to the solution - security requirements are included in the interface specification. Passing testing will suffice.\n\nOut of band - PHI may need to be transferred during a troubleshooting or privacy incident. "]
[2.1,"Information Asset Management Standard v1.8","[The EHR Solution] Program must implement and maintain an information and asset classification scheme for the confidentiality, availability and integrity of all information and assets it owns or manages. See Appendix A: [the EHR Solution] Information and Asset Handling Classification Scheme.","Must",null,"Program Office"]
[2.2000000000000002,"Information Asset Management Standard v1.8","[The EHR Solution] Program must label information and assets in accordance with the labeling requirements listed in section 2.2 of the policy.","Must",null,"Program Office"]
[2.2999999999999998,"Information Asset Management Standard v1.8","Although not required, [The EHR Solution] Program should label information and assets according to their integrity and availability classification.","Should",null,"Program Office"]
[2.4,"Information Asset Management Standard v1.8","[The EHR Solution] Program must ensure that all PHI and all assets that process or store PHI are protected, at a minimum, in accordance with Appendix B: Information and Asset Handling Protection Requirements. [The EHR Solution] Program may choose to implement additional controls than those required in Appendix B.","Must",null,"Program Office"]
[2.5,"Information Asset Management Standard v1.8","When information is combined or aggregated with information of a lower classification, [the EHR Solution] Program must ensure that the highest classification level contained therein shall determine, at a minimum, the overall classification of all the information.","Must",null,"Program Office"]
[2.6,"Information Asset Management Standard v1.8","[The EHR Solution] Program must ensure that all copies of paper material classified as Restricted must be individually numbered at time of creation and a master list associating each numbered copy with the individual that it was distributed to is maintained.","Must",null,"Program Office"]
[2.7,"Information Asset Management Standard v1.8","[The EHR Solution] Program must remove all information (PHI and [the EHR Solution] information) classified as Internal or higher from integrated storage devices and removable media prior to being sent externally. The removal of information classified as Confidential or higher must be done in a manner such that the information cannot be recovered and viewed.","Must",null,"Program Office"]
[2.8,"Information Asset Management Standard v1.8","[The EHR Solution] Program must log the destruction of the PHI in [the EHR Solution] CDR, as soon as possible, but no longer than 5 days after the destruction. At a minimum the log must include:\n- Date that the PHI was destroyed\n- Description of the scope of PHI that was destroyed\n- Description of how the PHI was destroyed\n- Identity of the person who destroyed the PHI, and\n- Identity of the person who authorized destruction of the PHI.","Must",null,"Program Office"]
[null,"Information Security Policy v2.8",null,null,null,"null"]
[1.1000000000000001,"Information Security Policy v2.8","[The EHR Solution] Program and HICs must define behavioural requirements governing the acceptable use of information and information technology to which [the EHR Solution]’s agents and Electronic Service Providers, and HICs, their agents and Electronic Services Providers with access to [the EHR Solution] must adhere.\n\nRefer to the Acceptable Use of Information and Information Technology Standard.","Must","Top Management","Program Office",null,null,null,null,null,"Typically an organization would implement these types of controls through an Acceptable Use Policy or Information Security Policy.","Agents and Electronic Service Providers of the organization participating in the EHR Solution"]
[1.2,"Information Security Policy v2.8","[The EHR Solution] Program and HICs must foster an information security-positive culture. This may be achieved by implementing an information security awareness and education program to help all persons with access to [the EHR Solution] to understand their information security-related obligations.\n\nRefer to the Privacy and Security Training Policy.","Must",null,"Program Office",null,null,null,null,null,"Typically an organization would implement these types of controls through a training program.\n\nVarious Connecting Ontario security and privacy training modules are available. At this time, Clinical End User, System Administrator, Local Registration Authority, and Privacy / Security Officer training modules are available.","Agents and Electronic Service Providers of the organization participating in the EHR Solution"]
[1.3,"Information Security Policy v2.8","[The EHR Solution] Program must perform information security threat risk assessments (TRAs) and EHR security assessments on [the EHR Solution] and must track, and mitigate or formally accept all of their risks that are identified through a TRA and a security assessment.\n\nRefer to the Threat Risk Management Standard.","Must",null,"Program Office"]
[1.4,"Information Security Policy v2.8","HICs should perform information security TRAs on their identity provider services and data contribution endpoints.\n\nRefer to the Threat Risk Management Standard.","Should",null,"Data Contributor \nIdentity Provider "]
[1.5,"Information Security Policy v2.8","[The EHR Solution] Program must implement cryptographic solutions in [the EHR Solution] to protect the confidentiality and integrity of PHI where appropriate, as well as to confirm the identity of the originator of a communication.\n\nRefer to the Cryptography Standard.","Must",null,"Program Office"]
[1.6,"Information Security Policy v2.8","HICs must implement cryptographic solutions on their relevant information systems to protect the confidentiality and integrity of PHI that is accessed through [the EHR Solution].\n\nRefer to the Cryptography Standard.","Must",null,"Data Contributor \nIdentity Provider "]
[1.7,"Information Security Policy v2.8","[The EHR Solution] Program must classify and define protection requirements for PHI in [the EHR Solution] in a manner that protects its confidentiality, integrity, and availability in any from (e.g., paper or electronic) throughout its information lifecycle.\n\nRefer to the Information and Asset Management Standard.","Must",null,"Program Office"]
[1.8,"Information Security Policy v2.8","[The EHR Solution] Program and HICs must establish appropriate access and identity management controls to manage all person and information system access to [the EHR Solution]. These controls must:\n- Define the information security responsibilities of all persons who have access to [the EHR Solution]\n- Ensure that only authorized persons are granted access to [the EHR Solution] and that personal accountability is assured\n- Ensure that only authorized information systems are granted access to [the EHR Solution], and\n- Provide authorized persons or information systems with only the least amount of privileges that are sufficient to enable them to perform their duties but do not permit them to exceed their authority.\n\nRefer to the Access Control and Identity Management Standard for System Level Access and the Identity Federation Standard.","Must",null,"Program Office"]
[1.9,"Information Security Policy v2.8","[The EHR Solution] Program must log and monitor all access to [the EHR Solution], and must log and monitor information system events on [the EHR Solution].\n\nRefer to the Security Logging and Monitoring Standard.","Must",null,"Program Office"]
["1.10","Information Security Policy v2.8","HICs must log and monitor all access by the HIC, their agents or Electronic Service Providers to [the EHR Solution]’s Provider Portal, and must log and monitor information system events on their identity provider services and data contribution endpoints.\n\nRefer to the Security Logging and Monitoring Standard.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1100000000000001,"Information Security Policy v2.8","[The EHR Solution] Program must implement controls to secure their network infrastructure, and establish procedures to secure the ongoing management and operation of [the EHR Solution].\n\nRefer to the Network and Operations Standard.","Must",null,"Program Office"]
[1.1200000000000001,"Information Security Policy v2.8","HICs must implement controls to secure their network infrastructure, and establish procedures to secure the ongoing management and operation of their identity provider services and data contribution endpoints.\n\nRefer to the Network and Operations Standard.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1299999999999999,"Information Security Policy v2.8","[The EHR Solution] Program must define information system development and change control requirements, and ensure that all system development activities performed on [the EHR Solution] are carried out in accordance with these requirements.\n\nRefer to the System Development Lifecycle Standard.","Must",null,"Program Office"]
[1.1399999999999999,"Information Security Policy v2.8","HICs should define information system development and change control requirements and ensure that identity provider services and data contribution endpoint development activities are carried out in accordance with these requirements.\n\nRefer to the System Development Lifecycle Standard.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1499999999999999,"Information Security Policy v2.8","[The EHR Solution] Program must ensure that their Electronic Service Providers who will have access to [the EHR Solution], or who manage or provide support to [the EHR Solution] have adequate information security controls in place to protect and maintain the level of confidentiality, integrity and availability.\n\nRefer to the Electronic Service Provider Standard.","Must",null,"Program Office"]
[1.1599999999999999,"Information Security Policy v2.8","HICs must ensure that their Electronic Service Providers who will have access to their identity provider services or data contribution endpoints, or who manage or provide support to these systems have adequate information security controls in place to protect and maintain the level of confidentiality, integrity and availability.\n\nRefer to the Electronic Service Provider Standard.","Must",null,"Data Contributor \nIdentity Provider "]
[1.17,"Information Security Policy v2.8","[The EHR Solution] Program must implement controls to protect against the risks of unauthorized physical access and environmental damage to [the EHR Solution].\n\nRefer to the Physical Security Standard.","Must",null,"Program Office"]
[1.18,"Information Security Policy v2.8","HICs must implement controls to protect against the risks of unauthorized physical access and environmental damage to their identity provider services and data contribution endpoints.\n\nRefer to the Physical Security Standard.","Must",null,"Data Contributor \nIdentity Provider "]
[1.19,"Information Security Policy v2.8","[The EHR Solution] Program must implement procedures necessary to ensure that [the EHR Solution]:\n- Remains available, especially in the event of a disaster, or\n- Can be recovered in the event that operations are disrupted.\n\nRefer to the Business Continuity Standard.","Must",null,"Program Office"]
["1.20","Information Security Policy v2.8","HICs should develop business continuity plans to ensure that their identity provider services and data contribution endpoints:\n- Remain available, especially in the event of disaster, or\n- Can be recovered in the event that operations are disrupted.\n\nRefer to the Business Continuity Standard.","Should",null,"Data Contributor \nIdentity Provider "]
[1.21,"Information Security Policy v2.8","[The EHR Solution] Program and HICs must implement an information security incident management process to identify and resolve information security incidents related to [the EHR Solution] or [the EHR Solution] quickly and effectively, while minimizing their impact and reducing the risk of similar information security incidents from occurring.\n\nRefer to the Information Security Incident Management Standard.","Must","Top Management","Program Office"]
[1.22,"Information Security Policy v2.8","HICs must identify and mitigate privacy and security risks and areas of non-compliance in respect of [the EHR Solution], including through privacy and security readiness self-assessments, privacy and security operational self-attestations, auditing and monitoring activities and assurance of agents and Electronic Service Providers.\n\nRefer to the Privacy and Security Harmonized Assurance Policy.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Participation in the readiness assessment and operational attestation to completion meets this requirements.\n\nHICs must also agree to follow the auditing requirements of the EHR  Policies.\n\nHICs must acknowledge requirement.","Scope includes:\n\nPrivacy and Security readiness self-assessments\nPrivacy and Security operational self-attestations\nAuditing and Monitoring Activities of Agents and ESPs"]
[1.23,"Information Security Policy v2.8","[The EHR Solution] Program Office must identify and mitigate privacy and security risks and areas of non-compliance in respect of [the EHR Solution], including through privacy impact assessments, threat risk assessments, privacy and security readiness self-assessments, privacy and security operational self-attestations, auditing and monitoring activities and assurance of agents, Electronic Service Providers and third parties.\n\nRefer to the Privacy and Security Harmonized Assurance Policy.","Must",null,"Program Office"]
[2.1,"Information Security Policy v2.8","All shall/must requirements are mandatory. Any deviation from a mandatory requirement in a [the EHR Solution] information security policy, standard, or supporting document must be approved by the Applicable Oversight Body.","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"HICs must communicate non-compliance initially in the self-assessment process and ongoing.  Those non-compliance items must be approved before beginning Clinical Validation and Viewing of PHI\n\nHICs must acknowledge requirement and ensure processes are in place to communicate non-compliance.","Scope includes IDP, EHR Security Policies."]
[2.2000000000000002,"Information Security Policy v2.8","All information security exception requests must be assessed by the eHealth Ontario Privacy and Security Operations Team and then reviewed by the Applicable Oversight Body for approval.","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"HICs must communicate non-compliance initially in the self-assessment process and ongoing.  These items must be reviewed by the Privacy and Security Operations group and approved by the Applicable Oversight Body.","Scope includes IDP, EHR Security Policies."]
[2.2999999999999998,"Information Security Policy v2.8","[The EHR Solution] Program must log all information security exception requests.","Must",null,"Program Office"]
[2.4,"Information Security Policy v2.8","Information security exceptions may be requested and granted for any length of time. However, all approved exceptions must be reviewed by the eHealth Ontario Privacy and Security Operations Team at a minimum, every two years, to ensure that the level of risk has not increased or that new risks have not appeared. If the eHealth Ontario Privacy and Security Operations Team reassesses the risk at a higher level or identifies additional risks, then the exception must be presented to the Applicable Oversight Body for re-approval.","Must",null,"Program Office"]
[2.5,"Information Security Policy v2.8","The Applicable Oversight Body has the right to revoke any approved information security exceptions. However, participants must be provided with at least six months to comply with the policy if their information security exception is revoked.\n\nRefer to Appendix A: Information Security Exception Requests","Must",null,"Program Office"]
[null,"Federation Identity Provider Standard v1.7",null,null,null,"null"]
[1.1000000000000001,"Federation Identity Provider Standard v1.7","During the accreditation process, Ontario Health Digital Services will review the Identity Access Management System (IAMS) of the IDP.\nThe IDP must:\n• Attest that it has the necessary authority, personnel and technical resources necessary to provide IA Services;\n• Assist in the Agency’s review by providing the documentation or other information required;\n• Advise the Agency of any changes to its IAMS and Registration or Authentication policies, practices, processes or technologies; \n• Agree to comply with and assist the Agency in complying with all applicable Laws and Regulations, such as the PHIPA and the FIPPA; \n• Agree to comply with all applicable agreement(s);\n• Respond to any recommendation made by the Agency or its delivery partners for remedial action to address any gaps identified by its reviews; and\n• Designate one or more Representatives to liaise with the Agency.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow","Related to IDP services the organization undertakes."]
[1.2,"Federation Identity Provider Standard v1.7","In exceptional cases, an IDP may request an exemption from one or more requirement(s) in this Standard in writing to the Agency, which must state the reason(s) for the request.  All requests shall be submitted to the Agency prior to the IDP providing or continuing to provide any IA Services.  All requests shall be reviewed and must be approved by the appropriate Agency team(s).  The Agency shall work with the IDP and may make recommendation(s) that would bring the IDP into compliance.  Such recommendation(s) may be subject to conditions, including requiring that compliance be achieved within a time period that is determined by the Agency, in accordance with the agreement between the Agency and the IDP.\nIf the IDP does not implement the recommended changes, or does not implement the recommended changes in accordance with any stated condition(s), the Agency shall:\n• Not accredit the IDP; or \n• Undertake such other measure in accordance with the agreement between the Agency and the IDP.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow","Related to IDP services the organization undertakes."]
[1.3,"Federation Identity Provider Standard v1.7","The Agency may collect, record, use or disclose information  for the purposes of Registration and/or Enrolment into any Federated Services, so as to reflect , for example, changing business need or to comply with applicable Laws and Regulations.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow","Related to IDP services the organization undertakes."]
[1.4,"Federation Identity Provider Standard v1.7","The IDP must notify the Agency of any subsequent changes to an IAMS that the Agency had accredited and to any of its Registration or Authentication policies, practices, processes or technologies, in accordance with the terms of the agreement(s) with the Agency or as soon as reasonably practicable, and prior to implementing any changes where they may require the Agency’s approval.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow","Related to IDP services the organization undertakes."]
[1.5,"Federation Identity Provider Standard v1.7","The Agency may repeat all or part of the accreditation review as required, for reasons including their modification or to audit for compliance with any Federation policy or standard.\nThe Agency shall conduct or repeat a review if, at any time, it is advised, suspects or otherwise detects that significant changes have been made to an IAMS or the Registration and Authentication policies, practices, processes or technologies of an IDP.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow"]
[1.6,"Federation Identity Provider Standard v1.7","The use of an IAMS may be terminated by the Agency or an IDP with reasonable notice, in accordance with the terms of the agreement(s) between them.  ","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow"]
["2.1.1","Federation Identity Provider Standard v1.7","The IDP may suspend an account if:\n• Information is discovered or revealed suggesting a reasonable likelihood that the information, documentation or any other matter provided or done to establish the Registration was misleading, false or fraudulent; \n• An End User has failed to comply with any Federation policy, standard, agreement or the terms and conditions of any Federated Service; or\n• Suspension is requested by an IDP or End User for any reason (e.g., leave of absence).\n\nPlease also see requirements on suspending accounts when passwords remain unused for the periods specified in section 4.3.6.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow.  Ensure your processes support this.","Related to IDP services the organization undertakes."]
["2.1.2","Federation Identity Provider Standard v1.7","The Agency reserves the right to immediately suspend access to Federated Services by an End User if it reasonably believes that there is an emergency or other circumstance that would warrant such action, including but not limited to a compromise of the Federated Services or the integrity of data therein.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review and acknowledge policy requirements and agree to follow"]
["2.1.3","Federation Identity Provider Standard v1.7","An account that has been suspended by the IDP due to possible misleading, false or fraudulent information must not be used or reactivated unless it has been confirmed that the relevant information, documentation or other material facts are true, accurate and complete.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations should have a process to investigate suspended registrations due to misleading, false or fraudulent information and must not reactivate these accounts until investigations have been done and items check out. \n\nThis may involve looking into the registration system for evidence, verifying with HR, etc.","Related to registrations the IDP configures."]
["2.1.4","Federation Identity Provider Standard v1.7","The IDP must document and retain a record of the reason(s) for a suspension and any resulting actions taken, including any investigation.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Where accounts are suspended, a record must be maintained.  This could be tracked in a ticket system or in a registration system.","Related to registrations the IDP configures."]
["2.2.1","Federation Identity Provider Standard v1.7","The IDP must revoke the account of an End User if:\n\n- The individual no longer needs the account (e.g. he/she is deceased; has resigned or retired);\n- It is determined that the account concerned is a duplicate;\n- It is determined that the information, documentation or any other matter provided or done to establish the Registration was misleading, false, or fraudulent; or\n- The identity has been otherwise compromised (e.g., identity theft).\n\nThe IDP may revoke the account of an End User upon request by that End User for any reason.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"The organization should have processes to resolve duplications, handle terminations, false or misleading registrations, identity theft, or other incidents.","Related to registrations the IDP configures."]
["2.2.2","Federation Identity Provider Standard v1.7","The IDP must document and retain a record of the reason(s) for a revocation and any resulting actions taken, including any investigation.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to include records of these type of activities in their Registration System / Processes","Related to registrations the IDP configures."]
[3.1,"Federation Identity Provider Standard v1.7","Each HIC must ensure that a Legally Responsible Person (LRP) or their delegate identifies at least one or more persons to act as a Local Registration Authority (LRA) to manage the enrollment of its agents and Electronic Services Providers who require access to Federation Services.\nThe LRP must ensure that a new LRA:\n• Has the time and resources required to perform the duties\n• Is stable in his or her current position (not subject to reassignment)\n• Meets Level 2 assurance(see section 3.3) qualifications according to the Federation Identity Provider Standard, and\n• Understands the importance of policy adherence, especially privacy and information security.\n","Must",null,"Identity Provider \nProgram Office"]
["3.1.1","Federation Identity Provider Standard v1.7","Modifications to the status of an approved LRA may be based on a request from the LRP, or at the discretion of the Registration Authority (RA) if it is suspected or discovered that the LRA is non-compliant with relevant policies, procedures or agreements. If the status of a LRA is revoked or suspended, the LRP must submit a request to lift the suspension before the status may be reinstated.","Must",null,"Identity Provider \nProgram Office"]
["3.1.2","Federation Identity Provider Standard v1.7","eHealth Ontario or its delegate, acting as a RA, must maintain a copy of all requests to approve, suspend or revoke a person’s status as LRA.","Must",null,"Identity Provider \nProgram Office"]
["3.2a","Federation Identity Provider Standard v1.7","The IDP must validate the identity of End Users or their own Representatives during Registration and before issuing Credentials.  \nThe IDP may determine their respective Registration requirements for End Users.  However, at a minimum, the IDP must:\n• validate Validate the Core Identity Information set out in section 3.2.1;\n• ensure Ensure the method(s) used attain(s) the required Level of Assurance; and\n• ensure Ensure that each individual being Registered:\no Is 16 years of age or older;\no Presents sufficient information to validate identity and positively Authenticate the individual upon subsequent access requests to Federated Services. \nThe End Users must present 2 pieces of identification, at least one identity document that contains a photograph bearing a true likeness of the End User (see section 15 for a list of Primary Documents and Secondary Documents that are currently accepted for Registration). \nHowever, this would not be required where a prior direct or personal interaction between the IDP and the Registrant has taken place to validate the individual’s identity and the IDP has records to support this.  In addition, the IDP must not accept a Health Number from any province, including Ontario, or a Social Insurance Number to confirm individuals’ identities for the Agency’s products and services, including Federated Services.\nIn addition, the IDP’s Registration requirements are expected to be of comparable or greater stringency than ONE®ID requirements.  For further information, please refer to the eHealth Ontario ONE® ID Policy and associated standards.  \nRefer to section 16: Enrolling an Agent or Electronic Service Provider with Access to [the EHR Solution] for the process of enrolling new agents or Electronic Service Providers with access to [the EHR Solution]. \n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to develop business processes to support these activities including assigning dedicated resources to handle these responsibilities.\n\nConsider leveraging HR processes as much as possible where some of these items may be handled.","Related to registrations the IDP configures."]
["3.2b","Federation Identity Provider Standard v1.7","Special requirements for Patient Access to Patient Portals/Applications \n\nIdentify Validation \n\n1. Patients must register for access in person.  Where required, remote registration can be permitted and must be done only over a secure video applications. (i.e. Skype or WebEx, etc.,)\n\n2. Under special circumstances (i.e. patient out of country, extreme illness, excessive travelling distance, etc.), registration over the phone is permitted.  Users must answer correctly at least the following 6 questions: \n• Date of Birth\n• Address and Postal Code\n• Health Care Number (HCN)\n• Name of Family Doctor\n• Name of Emergency Contact\n• Name of Next Kin     \n\n3. Patients must be 14 years of age or older in order to register for an account to access their own medical records.\n\n4. Using a Health Card with photo is an acceptable Primary ID for a patient to register for access to a Patient Portal/Application.\n\nSelf-completion phase of Registration \n\n Upon successful identity validation, patient may receive a PIN for self-registration purpose.  The PIN must\n5.  be: \n• Unique, random and at least 6 characters long \n• No complexity is required \n• Can be valid only for 30 days, otherwise PIN regeneration is required.\n\n6. The patient portal/application must prompt patients to provide at least the following information when completing the self-registration phase: \n• PIN\n• Date of Birth\n• Patient’s Medical Record Number (MRN)\n\nSubstitute Decision Maker (SDM) Access to a Patient’s Record  \n\n1. Where a Substitute Decision Maker requests access to a Patient’s record, the following documentation must be provided in person:\n• A fully filled and signed delegate form provided by [the EHR Solution] Program Office.\n• One identity document that contains a photograph bearing a true likeness of the SDM (see section 13 for a list of Primary Documents and Secondary Documents that are currently accepted for Registration).\n• Supporting documentation such as a long-form birth certificate, power of attorney documents, will and death certificate, or other acceptable court documents.\n\nNote: \n\n• For auditing purposes, the application must capture and store data on confirmation of identity verification, the provider who performed the identification, and any supporting documentation.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to develop business processes to support these activities including assigning dedicated resources to handle these responsibilities.\n\nConsider leveraging HR processes as much as possible where some of these items may be handled.","Related to registrations the IDP configures."]
["3.2.1","Federation Identity Provider Standard v1.7","The following is the Core Identity Information the IDP must collect in order to Register an End User: \n• Legal name;  and \n• Where applicable, all professional designations and license numbers of the individual.\n\nWhere the organization leverages the ONE ID Provincial 2 factor authentication service the telephone number of the End User must be recorded and maintained securely. \n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to include records of these type of activities in their Registration System / Processes","Related to registrations the IDP configures."]
[3.3,"Federation Identity Provider Standard v1.7","During Registration, the IDP must assign every End User the following:\n• A unique User ID (see below);\n• The information required to set and maintain credentials (see section 4.2); and\n• A Level of Assurance (e.g. AL1, AL2, AL3) during the Registration of each End User corresponding to the rigour of the Registration process involved and the strength of the evidence offered to support the identity.\nThe IDP must ensure that End Users are assigned a User ID that uniquely identifies the End User within the Federated System.\nUser IDs must be in a format approved by the IDP.\nNote: ONE®ID’s standard format of User IDs for individuals is:\n• [preferred first name].[preferred last name]@[ONEID.on.ca], e.g. John.Doe@ONEID.on.ca.\n\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to develop business processes to support these requirements. \n\nSome of these items may be assigned and tracked in Active Directory or other Directory Services at the organization.","Related to registrations the IDP configures."]
["3.2.1","Federation Identity Provider Standard v1.7","The IDP must ensure that End Users are assigned a User ID that uniquely identifies the End User within the Federated System.\nUser IDs must be in a format approved by the IDP.\nNote: ONE®ID’s standard format of User IDs for individuals is:\n\n- [preferred first name].[preferred last name]@[ONEID.on.ca], e.g. John.Doe@ONEID.on.ca.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to develop business processes to support these requirements. \n\nA standard format should be developed by your organization.  Often the central directory service will be able to enforce unique IDs during provisioning.","Related to registrations the IDP configures."]
["3.4.1","Federation Identity Provider Standard v1.7","A Level of Assurance refers to the level of confidence that can be placed in an identity claim.  The Level of Assurance required for access to a Federated Service is determined by the Agency based, among other things, on Application Providers’ business requirements and the applicability and appropriateness of the identity requirements corresponding to different information classification, as set out \n\nThe IDP should consult the ONE® ID Identity Assurance Standard for further requirements relating to Levels of Assurance.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"During registration, the AL of the users must be recorded and maintained.  This could be maintained in a log that identifies the users who are in each AL.   Potentially, an Active Directory attribute could be extended to store this information.\n\nThe SAML assertion to eHealth Ontario must include this AL.","Related to registrations the IDP configures."]
["3.4.2","Federation Identity Provider Standard v1.7","The Agency typically requires all End Users’ electronic identities attain a minimum of AL2 in order to access Federated Services with PI or PHI.  Accordingly, the IDP must be capable of Registering and Authenticating End Users to AL2, at a minimum.  \nWhere an AL3 is required, the IDP must implement more rigorous Registration or Authentication measures such as:\n• Setting more stringent requirements for End User Credentials; and\n• Requiring a greater number of Authentication factors.\n\nAccess to some Federated Services may require End Users to be provisioned with access to other Federated Service(s). When multiple Enrolments are required, an End User’s AL must be greater than or equal to the highest AL required by the Federated Services.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Develop the organization's processes to support AL2 at minimum.  AL3 is not used extensively as of yet. Organizations need to broadly acknowledge requirement.","Related to registrations the IDP configures."]
[3.5,"Federation Identity Provider Standard v1.7","Identity must be corroborated where an AL3 is required.  Identity corroboration may either be by:\n• Direct verification by an Authoritative Party (e.g., Vital Statistics Agency, Revenue Canada); and/or \n• A trusted third-party professional (e.g., lawyer, doctor, minister).  \n\nIt may also involve the exchange or confirmation of shared secrets – information that is known by the corroborator about a potential Registrant.  For example, as in the passport model, a third-party may be required to confirm the length of time a potential Registrant has continuously resided in Canada. \nAuthoritative Parties\nSome examples of Authoritative Parties accepted by the Agency are listed below, corresponding to the categories of End Users:\n• Employees, could be the employer or a Canadian Police Information Centre (C.P.I.C.) check during the hiring process;\n• Corporations, could be a Corporate Registry;\n• Doctors, could be the College of Physicians and Surgeons; and\n• Citizens, could be the Vital Statistics Agency, Citizenship and Immigration, Revenue Canada or Revenue Quebec.\nIf in doubt, the IDP is advised to consult the Agency on whether a third-party would be accepted as an Authoritative Party for the purpose of identity corroboration. ","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Develop the organization's processes to support AL2 at minimum.  AL3 is not used extensively as of yet. Organizations need to broadly acknowledge requirement.","Related to registrations the IDP configures."]
[3.6,"Federation Identity Provider Standard v1.7","To Register at AL2:\n• All identity documents must contain a photograph of the End User;\n• Professional Designation(s) & Licence Number(s) (where applicable)\n\nTo Register at AL3:\n• All identity documents must contain a photograph of the End User;\n• A copy of the identity document must be taken and retained on record; and\n• Professional Designation(s) & Licence Number(s) (where applicable)\n• End Users must sign their Registration application with a handwritten signature.\n\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Where AL3 is used, the IDP must have established a process to do identity corroboration.\n\nNote, at this time AL3 is not used extensively and AL2 is sufficient for most application access (at this time).","Related to registrations the IDP configures."]
["3.7.1","Federation Identity Provider Standard v1.7","The IDP must maintain a list of assigned accounts used for consuming Federated Services for each End User, including the name of the authorizing personnel.  Such information must be made available to the Agency upon request or during an audit.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure a process is in place to validate the identity of individuals to a level required by the standard. Consider existing HR processes that would cover the current user base.","Related to registrations the IDP configures."]
["3.7.2","Federation Identity Provider Standard v1.7","An apparent duplication means a full match on all Core Identity Information (see section 3.2.1).  The IDP must have processes in place to identify and resolve apparent duplications, such as:\n• Referring the issue to the Health Information Custodian under whose delegation or authority the End User accesses or uses Federated Services; or\n• Confirming or requesting additional information or evidence from the End User. \n","Must",null,"Identity Provider \nProgram Office"]
["3.8.1","Federation Identity Provider Standard v1.7","The Legally Responsible Person (LRP) must identify a named person(s), group(s), or role(s) that has the authority to act as a Sponsor.","Must",null,"Identity Provider \nProgram Office"]
["3.8.2","Federation Identity Provider Standard v1.7","Access to applications and services vary based on the entitlement criteria of the data and application owner(s).  \nSome applications and data permit access for research while others prohibit access for research. Some applications are specifically for use by technical administrators.  Please refer to the Entitlement Procedures Guide for requirements to enrol End Users into applications and services.  \n• If an agent or Electronic Service Provider has multiple roles, e.g., is both a clinician and a risk manager, the Sponsor may assign that person with access to [the EHR Solution] for the purposes of collecting PHI for providing or assisting in the provision of health care and must ensure that the end user understands their permissions and obligations.  \n• Once access to [the EHR Solution] has been revoked, agents or Electronic Service Providers must re-enroll in order to have their access to [the EHR Solution] reinstated\nDocumentary Requirements\n• Name of the authorizing person Sponsoring the Entitlement\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure this process is available where AL3 is used.  At this time AL2 is being requested for Connecting Ontario.","Related to registrations the IDP configures."]
["3.8.3a","Federation Identity Provider Standard v1.7","• A review  of all active accounts and enrollments to the Federation Services must be completed at least an annually.\n• The review should be coordinated with the authorized Sponsor to ensure that all account access is appropriate and up to date. \n• Where discrepancies are found timely actions to rectify access privileges must be implemented.\n• Accounts that have not been used in more than 180 days must be suspended;.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to keep a log of the end users who have been provisioned and who the authorizing sponsor is.   This information may be maintained in the IAM provisioning software or other mechanism.","Related to registrations the IDP configures."]
["3.8.3b","Federation Identity Provider Standard v1.7","• For Patient Portals/Applications only, the patient must be notified that his/her account has been inactive for 365 days or more and take appropriate action.  If not response from the Patient, his/her account must be suspended.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations need to keep a log of the end users who have been provisioned and who the authorizing sponsor is.   This information may be maintained in the IAM provisioning software or other mechanism.","Related to registrations the IDP configures."]
[3.9,"Federation Identity Provider Standard v1.7","• The IDP must keep a record of End User Information, as well as any subsequent changes made to this information. \nThe IDP must retain its records of End User Information permanently and must transfer this information to the Agency in accordance with the agreement between it and the Agency. Permanent retention is required because it cannot be determined in advance when an access request may be made or a breach investigation may occur.  End User Information would be required in either case to tie accounts to End Users’ real world identities.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"LRAs must be aware of how duplicate accounts are resolved.  Ensure your organizations has developed a process which could include escalation to the IDP lead for your organization.","Related to registrations the IDP configures."]
[4.0999999999999996,"Federation Identity Provider Standard v1.7","Single-factor Authentication may be used when accessing the Federated System from a secure environment (e.g. using the Health Service Providers Managed Private Network).   Single factor Authentication would not be appropriate in all situations, such as when AL3 is required (see section 3.43.3).\n\nWithin the Federation, Authentication must involve two or more factors when Federated Services are accessed from:\n• The Internet or unsecured environments/locations;\n• A point-of-service application, such as a hospital Information System (HIS), if the user is remote (not on site); or\n• Where any Privileged function is being accessed, e.g. system administrator. \nStrong Authentication typically involves the use of a strong password (see section 4.2) combined with a second factor.  Examples of second factor technologies include: hard security tokens, call backs, SMS messages, Risk-Based Authentication, one-time passwords, machine certificates, biometrics and personal certificates.\nHowever, certain Federated Services may require the use of specific type(s) of second factors, e.g. hard security tokens.  In such cases, the required type(s) of second factors must be implemented in order to access the Federated Services in question.\nThe above principles regarding two-factor Authentication apply whenever Federated Services are accessed from browsers on portable electronic devices (e.g., smartphones, tablets).  \nSpecial requirements for Patient Portals/Applications \n1. The requirements for multi-Factor authentication continue to apply to Patient Portals/Applications by default.  To accommodate users, patient can be given the option to disable/opt-out multi-factor authentication during or after registration.  \n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure a record of the following is kept:\n\nRegistration information and updates:\n\n- The User ID;\n- The Level of Assurance that the IDP has assigned to the End User (section 3.3.2);\n- A time stamp;\n- Core Identity Information (legal name, professional designation(s) and license number(s)); and\n- The action performed and data element changes (from and to values).\n\nVerify that logs capture this information. Ensure that it is retained for the required period. (permanent).  An organization may keep this info in a registration system.","Related to registrations the IDP configures."]
[4.2,"Federation Identity Provider Standard v1.7","Where the IDP chooses to use Challenge Questions for Authenticating End Users, they must have processes and policies in place, such as:\n• Requirements on the nature or number of questions permitted or required;\n• Storage and transmission of answers to Challenge Questions;\n• End Users’ rights or obligations to set or change their Challenge Questions. \nIn addition, the IDP’ IAMS must ensure that:\n• End Users are prohibited from setting their own Challenge Questions (e.g., End Users must select from a pre-defined list instead);\n• Challenge Questions are connected to or affiliated with the Registration record of the respective End Users; and\n• Unauthorized persons are prevented from seeing or changing End Users’ Challenge Questions. \nFor the purpose of Authentication during a login, the use of Challenge Questions is permitted only where they are used in conjunction with:\n• Risk-Based Authentication mechanisms (e.g. device recognition); and\n• Heuristic tests (e.g. verifications of IP address or browser identity).\n\nFollow the link for more information regarding the ONE ID Challenge Question Standard\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"There are three main options:\n1. The Identity Provider can implement their own authentication mechanism that involves two or more factors.\n\n2. The HIS, can block access to EHR services for remote users.  This option would not allow users with that Identity Provider to access any EHR services, other than from a local  access point.  \n\n3. Longer term, ONE ID may make available on behalf of qualified Identity Providers, an authentication service that involves two or more factors.   An Identity Provider would have to be capable of holding and conveying key information for each user, e.g. their current telephone number(s), as well as secure processes to capture and maintain that key information.  Not all Identity Providers may qualify.  Note, please contact the ONE ID team for considerations of this option.","Related to authentication of end users to the EHR"]
[4.3,"Federation Identity Provider Standard v1.7"," Credentials include passwords, challenge questions and where the provincial 2 factor authentication services is used, the telephone number of the user is considered a credential and must be securely managed.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"continued from above","continued from above"]
["4.3.1","Federation Identity Provider Standard v1.7","The IDP is responsible for implementing appropriate measures to distribute, maintain and protect credentials.  The IDP must have a comprehensive credential management policy to ensure passwords of sufficient strength and complexity are used.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Verify that password requirements can be met.  Also verify capabilities for authenticating users with additional factors.","Related to authentication of end users to the EHR"]
["4.3.2","Federation Identity Provider Standard v1.7","The following requirements apply to passwords that may be used to Authenticate users accessing Federated Services.\n\n• The IDP must enforce strong passwords, which must:\no Be at least 8 characters long with a maximum not  less than 64 characters-long;  and\no Include characters / digits from at least three of the following conditions of complexity:\n At least 1 uppercase character (A through Z)\n At least 1 lowercase character (a through z)\n At least 1 numerical digit (0 through 9)\n At least 1 non-alphanumeric character (~!@#$%^&*_-+=’ |\\(){}[]:;\"'<>,.?/);\nTo permit no complexity, live screening of new passwords must be completed and displayed to users during password creation. Live screening must be done against a list of commonly used passwords: blacklist, dictionary, usernames, service names, sequential strings,, and passwords from previous breaches.\n•  Password history should prevent reuse of the last 5 passwords.\n• Where technology permits, passphrases must be used (e.g. 24SussexDrive) instead of a (typically shorter) password;\n• Where technology permits, software that prohibits the use of recognizable patterns must be used;\n\nPasswords must not include all or part of the End User’s first / last names or any easily obtained personal information (e.g. names of family members, pets, birthdays, anniversaries, all or part of a Login ID or a commonly known nickname); \n• Initial or temporary passwords must be unique, not guessable and must follow this Standard regarding password strength; \n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review the security of passwords in storage, transmission, and provisioning.  Develop processes to ensure passwords are protected throughout the lifecycle.","Related to authentication of end users to the EHR"]
["4.3.3","Federation Identity Provider Standard v1.7","• An initial password should be generated by an automated service and issued directly and securely to the End User (e.g. in person, by mail, telephone or encrypted email); \n• The IDP must ensure that the passwords are communicated to the intended End Users (e.g. they must be mailed to a confirmed postal or email address or a wire-line phone number of record); \n• The password distribution process must be auditable;\n• Systems passwords must not be given to staff or contractors who have not signed a non-disclosure agreement or who are otherwise not authorized to receive such information\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Organizations should consider if their infrastructure and authentication mechanisms can be integrated into a central directory system where these items can be enforced through a technical policy.  \n\nActive Directory will support most of these requirements.\n\nTraining can be leveraged to communicate password requirements which may not be technically feasible (e.g. pets name)","Related to authentication of end users to the EHR"]
["4.3.4","Federation Identity Provider Standard v1.7","• The IDP must first validate End Users’ identity before issuing any credentials for accessing Federated Services; \n• The IDP may choose its Authentication method(s), provided they are properly documented, i.e. by contacting the IDP’ service desks, which after validating an End User’s identity using information that only the End User should know (e.g. Challenge Questions), will issue a temporary password to the End User;\n• Helpdesk functions that assist in access control, especially credential resets, must not allow the personnel to see, hear or know End Users’ temporary passwords;\n• System administrators with global rights must not perform the function of creating and maintaining End User credentials;\n• Old credentials must not be released to End Users;\n• The briefest possible explanation must accompany a denial of access when a password does not conform to rules for creation and/or change of passwords. The message should provide contact information for End User assistance (e.g., “access denied – contact your system administrator”);\n• Access must be denied after five consecutive incorrect password attempts, for a duration of at least 30 minutes. The IDP shall record access denials due to the entry of five consecutive incorrect password attempts in an audit or system log, which must be reviewed and where warranted, investigated in accordance with monitoring and escalation procedures that the IDP has established approved and / or in accordance with the terms of the agreement(s) between the IDP and the Agency.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure a password management process is established which leverages the principles outlined.\n\nOften the LRA may be able to provide the password in person, an automated mechanism may be built to reset password, a helpdesk may be able to reset passwords after successful authentication of the user calling.","Password management of accounts used to access the EHR"]
["4.3.5","Federation Identity Provider Standard v1.7","• An IAMS must not display or echo the characters of a password on output devices or while being entered but may be represented on the screen by special characters such as asterisks; (Temporary visibility of passwords is permitted depending on technology limitations.);","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure a password management process is established which leverages the principles outlined.\n\nOften the LRA may be able to provide the password in person, an automated mechanism may be built to reset password, a helpdesk may be able to reset passwords after successful authentication of the user calling.","Password management of accounts used to access the EHR"]
["4.3.6","Federation Identity Provider Standard v1.7","• Permanent passwords for accessing Federated Services must expire after 90 day of their issuance or modification. Upto 1 year is permitted where the IDP is in compliance with the other supporting password controls outlined in the EHR Security Policies and IDP Standard. \n• Once a password has expired, access to Federated Services must be suspended until a new password is created.  \n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review the password input processes and ensure that the password is masked with asterisk **** or other methods to protect the password from being echoed to screen. Often this is a configurable option.\n\nEnsure that end users and system admins are trained on behaviour requirements related to password storage and security.","Password management of accounts used to access the EHR"]
["4.3.7","Federation Identity Provider Standard v1.7","An IDP must provide a secure mechanism for End Users to change, recover or reset their credentials (e.g. where an End User has been locked out or has forgotten his or her password).\n• The IDP shall require End Users to change their initial passwords on first use (if not set by the End User) \n• The credential reset process must include strong positive Authentication of the requester so that it can be performed for any End User who is not visually identifiable, (e.g., requests via the telephone).","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Passwords must be set to expire after 90 days.","Password management of accounts used to access the EHR"]
["4.3.8","Federation Identity Provider Standard v1.7","• When password lockers/storage software are implemented, these products must require strong passwords and secure authentication and transmission. \n• When applicable automated login by password locker must be authenticated by a strong password (or biometrics when possible). \n• Unsecure login methods such as macros scripts, screen scraping, function keys are not permitted\n• Browsers must not be used to store, autofill, cache passwords or any other forms fills.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Protocols need to be in place to manage changes to passwords. \n\nProcesses must be developed to meet the principles required","Password management of accounts used to access the EHR"]
["4.3.9","Federation Identity Provider Standard v1.7","• A Provincial Two Factor Authentication is offered as part of the risk-based authentication interdiction method and as such the phone challenge may be bypassed (if a recognized device) or the user may be denied access (if a risky IP or device) based on rules of the service.\n• Identity providers are responsible in determining when a user requires a challenge before allowing access to EHR. E.g. for remote users rather than for users physically within the four walls of the organization.  Identity Providers must use the authentication service only when necessary to access EHR assets.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Information provided is applicable to organizations that leverage the Provincial Two Factor Authentication Service.   HIC are responsible to determine when a user requires a challenge.","Applicable to organizations that leverage the Provincial Two Factor Authentication Service"]
["4.3.9.1","Federation Identity Provider Standard v1.7","• Identity Providers must capture and maintain securely the telephone numbers passed to the Federation Broker for the purpose of authenticating their users.\n• Identity Providers must provide telephone numbers that are not shared or go through a switchboard.  Note that initially at least, extensions, IVRs and TTYs will not be supported.\n• Identity Providers must ensure they are permitted to provide users’ telephone numbers for authentication purposes.\n• Identity Providers must have mechanisms in place to manage the accuracy of the telephone numbers that are passed to the Federation Broker and updating them.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"HICs must have processes to maintaining the phone number and ensure they are unique.","Applicable to organizations that leverage the Provincial Two Factor Authentication Service"]
[5,"Federation Identity Provider Standard v1.7","The IDP must ensure the accuracy of all assertions and comply with requirements in the Specifications. The IDP is liable for any inaccuracy in the identity assertions it submits to the Agency or other Federation members.\nUser IDs issued to End Users by the IDP must be sent as assertions in the acceptable format (see the Specifications) to the Agency or other Federation members to be captured in a central repository that will be hosted at and managed by the Agency.\nIn the event that the IDP becomes aware of an assertion of inaccurate attributes, the IDP must:\n• Notify the Agency immediately by contacting the eHealth Ontario Service Desk at 1-866-250–1554 as this may have implications of a Privacy Breach or Security Breach;\n• Take whatever action is necessary to correct the inaccuracy;\n• Follow recommendations and direction from the Agency if provided; and\n• Give notifications as required pursuant to the terms of the applicable agreement(s).\nWhere the IDP makes repeated assertions of inaccurate attributes, the Agency may suspend the use of the IDP’s IAMS and/or revoke the IDP’s accreditation, if the IDP fails to remedy such deficiencies within the cure period specified by the Agency. The Agency shall provide reasonable assistance to the IDP in order to remedy such deficiencies.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Often technical configurations can be implemented to force users to meet most of the password requirements.  Some must be implemented through training (e.g. do not use your pets name as a password)\n\nTo protect from brute force password attacks, accounts must be set to lockout after 5 password entry failures and events must be configured to alert the appropriate party and investigated.","Related to authentication of end users to the EHR"]
[6,"Federation Identity Provider Standard v1.7","The IDP must implement access control systems or procedures that:\n• Provide End Users with a written statement of their access rights and responsibilities (e.g. delineate rules relating to the kinds of data, files or information that could only be accessed by specified personnel); \n• Require End Users to indicate their acceptance of disclosed access rights and responsibilities; \n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure that default / built in accounts have their password changed or disable the account as part of your system hardening practices.\n\nEnsure products like Wireshark or other packet capture software are not leveraged.","Consider IDP infrastructure in scope."]
[7,"Federation Identity Provider Standard v1.7","The IDP must deny authentication from End Users with suspended, expired or revoked Credentials.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review this requirement in conjunction with the Cryptography policy. \n\nEnsure that cryptographically secure transmission methods are in place where passwords are entered. (e.g. log on screen of HIS)\n\nEnsure that the storage of the passwords is done securely, the password should not be stored in cleartext, verify the hashing algorithm where passwords are stored to ensure it meets the policy.\n\nReview the currency of your cryptography implementation, recent vulnerabilities such as POODLE and negotiate encryption down to a non-secure method and potentially allow for data interception.\n\nTo note, eHealth Ontario will issue the organization the certificate required to authenticate the SAML requests coming from the IDP infrastructure at the HIC organization.","Consider IDP infrastructure in scope as well as User workflows."]
[8,"Federation Identity Provider Standard v1.7","The IDP must create a session key to Authenticate subsequent data transmission in the same session.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"\nEnsure that the storage of the passwords is done securely, the password should not be stored in cleartext, verify the hashing algorithm where passwords are stored to ensure it meets the policy.","Consider IDP infrastructure in scope."]
[9.1,"Federation Identity Provider Standard v1.7","The IDP must keep audit logs that contain at least the following information:\nAuthentication:  \n• The User ID;  \n• Authentication outcome (e.g. failed / successful); \n• Authentication data (e.g. type of challenge used and Authentication-related details); and\n• A date and time stamp.\nThe Agency is required by law when acting as Health Information Network Provider (HINP) to take steps that are reasonable in the circumstances to keep an electronic record of all accesses to all or part of the personal health information contained in the electronic health record, and to ensure that record identifies the person(s) who accessed the information and the date, time and location of the access. Where required, the IDP shall assist the Agency in fulfilling this regulatory requirement.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"The IDP will undergo access method testing validation which will ensure that the organization can send SAML assertions to the EHR Solution in the required format. \n\nOrganizations need to broadly acknowledge","Related to IDP assertions used to access the EHR"]
[9.1999999999999993,"Federation Identity Provider Standard v1.7","The IDP must retain audit logs of:\n• Authentication events 60 days online and 24 months minimum in archive; \n• End Users’ Credentials information permanently; and\n• Events relating to its IAMS for 60 days online and 24 months total in archive. See the EHR Security Logging and Monitoring Policy for more details.\nThe IDP must retain its audit logs for the periods set out in this section and must transfer this information to the Agency in accordance with the agreement between it and the Agency. Audit logs would be required in either case to tie accounts to End Users’ real world identities.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure a use case is developed and proper awareness is in place with the IAM staff to communicate to eHealth Ontario where SAML assertions may have been inaccurate.","Related to IDP assertions used to access the EHR"]
[9.3000000000000007,"Federation Identity Provider Standard v1.7","The IDP must ensure that audit logging is operational at all times. Registration, modification of Registration information or Authentication must not be performed if audit logging is not functioning.  ","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Publish an Acceptable Use Policy for your organization or the HIS specifically.  Ensure that end users agree to this as part of training or a click through.\n\nEnsure the IAM infrastructure and processes are available 24*7 to serve the users.","Accounts used to access the EHR"]
[9.4,"Federation Identity Provider Standard v1.7","The IDP must secure access to audit records and logs and safeguard access to system audit tools to prevent misuse or compromise.\nThe IDP must implement appropriate security measures to protect audit records and logs from being tampered with, such as:\n• Implementing segregated network segments with appropriate access controls; or \n• Directing audit logs to a Security Information and Event Management (SIEM) system.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"If challenge questions are used when validating identities, review the requirements and implement a process that can meet the requirements.","Accounts used to access the EHR"]
[10.1,"Federation Identity Provider Standard v1.7","The IDP Services must be available 24 hours a day, 7 days a week.\n\nFor IDPs using the Provincial Two Factor Authentication service, service desks must be equipped to handle calls from impacted users and have the ability to correct issues 24 hours a day, 7 days a week, e.g. modify the telephone number quickly and securely. This may include implementing an appropriate error handling process for errors that occur during the challenge, for example, a user cannot complete the challenge because their phone cannot get a signal.  \n\nWhere IDPs are using the Direct call method of the Provincial Two Factor Authentication, they must have the ability to monitor failed OOBA challenges and take appropriate action if required. ","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Technical mechanisms can be configured to reject these situations.","Accounts used to access the EHR"]
[10.199999999999999,"Federation Identity Provider Standard v1.7","The IDP must Register and Enrol personnel responsible for performing End Users’ Registration and Authentication and to assist End Users with issues related to its IA Services, within the scope of authority delegated by the IDP.\nWhen required, the IDP is also expected to transfer calls to and receive calls from the eHealth Ontario Service Desk or those of other Federation members.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Session management is important to ensure that outsiders can not interfere with messages.  Verify the session management of your IAM services. Some testing can be done to see if sessions can be resumed after \"terminated\".","Sessions related to accounts used to access the EHR"]
[10.3,"Federation Identity Provider Standard v1.7","Representatives for the IDP must be Registered at AL2 or above.  The IDP’ Registration agents cannot Register End Users at a Level of Assurance that is higher than their own Level of Assurance, regardless of the number of identity documents presented by the End User or the type of identity validation performed.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Review the logs generated from the IAM system and ensure that it has at least the following captured:\n\nAuthentication:\n- The User ID;\n- Authentication outcome (e.g. failed / successful);\n- Authentication data (e.g. type of challenge used and Authentication-related details); and\n- A date and time stamp. ","Audit logs related to IDP processes"]
[10.4,"Federation Identity Provider Standard v1.7","The IDP must provide their Representatives with access to only the information required to carry out their assigned duties.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Consider the logs that are produced in the IAM workflow from registration, modifications, revocation, authentication, password resets, etc. Ensure that these logs are captured and retained securely.\n\nReview the supporting infrastructure that is being used to run the IAM services.  Ensure that those logs are being archived for the period of time necessary.  Review the Security Logging and Monitoring Policy for specifics on system logs to consider.","Consider the logs that are produced in the IAM workflow from:\n\n- registration,\n- modifications\n- revocation\n- authentication\n- password resets\n\nConsider technology logs supporting the IAM services."]
[10.5,"Federation Identity Provider Standard v1.7","The IDP must Authenticate individuals who contact their Representatives through well-defined processes.  At a minimum, the IDP must require individuals to present evidence of identity that is equivalent to that required at initial Registration or information that only the End User should know, e.g. Challenge Questions.","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Ensure that the logging within your system is always active to capture events from the IAM services.\n\nConsider deploying a configuration that would halt the system authentication if logging is not functioning. Consider configuring event monitoring to ensure that logging continues to run.","Consider the logs that are produced in the IAM workflow from:\n\n- registration,\n- modifications\n- revocation\n- authentication\n- password resets\n\nConsider technology logs supporting the IAM services."]
[11,"Federation Identity Provider Standard v1.7","The IDP will maintain privacy and security procedures, practices and controls in compliance with Applicable Laws and follow the eHealth Ontario EHR Security Policies when providing IA Services.\nThe Agency may change or add to these policies as the requirements of the Federation evolve over time. Members of the Federation, namely IDPs, must adjust their service delivery to comply with these requirements as updated from time to time within a given time period according to the eHealth Ontario Identity Federation Identity Provider Policy and/or the agreement between the member and the Agency.\n","Must",null,"Identity Provider \nProgram Office",null,null,null,null,null,"Implement logical and physical access controls to protect records. Offload events such as identity provisioning, registration, authentication to a SIEM solution or dedicated log server where it is in electronic form.\n\nEnsure paper records are secured and retained.","Consider:\n\n- registration information\n- secret questions/answers\n- identity provisioning infrastructure\n- authentication logs"]
[null,"Information Security Incident Management Standard v1.8",null,null,null,"null"]
[1.1000000000000001,"Information Security Incident Management Standard v1.8","HICs must implement an information security incident (“incident”) management process that covers all phases of the incident management process to deal with incidents related to [the EHR Solution]:\n- Identification/Triage\n- Response\n- Recovery, and\n- Follow-up","Must","HR","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"HICs must have a documented process to handle incidents including establishing roles and accountabilities.   Use cases should be considered to respond to probable incidents (e.g. malware, password compromise, etc.)\n\nNIST Publication - Incident Response may be helpful to review when planning your incident response program:\nhttp://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf\n\nA security incident reporting template is available on request which can be used to track the required incident details and can be used for notifications.","Scope includes security incidents that impact the EHR Solution.","A security incident reporting template is available on request which can be used to track the required incident details and can be used for notifications."]
[1.2,"Information Security Incident Management Standard v1.8","If at any point in the incident management process a HIC realizes that the incident has resulted in a privacy breach, then the incident must be handled in accordance with the Privacy Breach Management Policy.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Be familiar with the EHR Privacy Breach Management Policy. Recognize that when PHI is involved that this is a Privacy Breach.\n\nThe Security officer and Privacy Officer training includes these messages.","Scope includes security incidents that impact the EHR Solution."]
[1.3,"Information Security Incident Management Standard v1.8","HICs must establish a point of contact to whom actual or suspected incidents related to [the EHR Solution] are reported. Most often, the point of contact is a service desk.","Must","Training","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Assign an individual or group as a point of contact.  In small organizations this may be an office manager.  These individuals must be aware of the protocol to deal with incidents.","Scope includes security incidents that impact the EHR Solution."]
[1.4,"Information Security Incident Management Standard v1.8","HICs must ensure that their agents and Electronic Service Providers are aware of their responsibility to immediately report actual or suspected incidents to the established point of contact.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Ensure your Agents and ESPs take the relevant training courses provided by Connecting Ontario which include the requirements to communicate incidents. ","Scope includes security incidents that impact the EHR Solution."]
[1.5,"Information Security Incident Management Standard v1.8","The point of contact must generate an incident ticket or log for all reported incidents related to [the EHR Solution]. At a minimum, the incident ticket must contain the following elements:\n- The time and date of the reported incident\n- The name and contact information of the agent or Electronic Service Provider that reported the incident\n- Details about the reported incident, (e.g., type and how it was detected)\n- Any impacts of the reported incident, and\n- Any actions undertaken to contain the incident either by the agent or Electronic Service Provider that reported the incident or the point of contact.\n","Must","Training","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"A security incident report template is available on request which includes the required fields and can be used to track this activity.","Scope includes security incidents that impact the EHR Solution.","A security incident reporting template is available on request which can be used to track the required incident details and can be used for notifications."]
[1.6,"Information Security Incident Management Standard v1.8","HICs must appoint an incident response lead or team who is responsible for initiating the triage, response, recovery and follow-up activities for incidents related to [the EHR Solution] The incident response lead or team may be the same as the point of contact.","Must","Training","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Assign an individual or group as a point of contact.  In small organizations this may be an office manager.  These individuals must be aware of the protocol to deal with incidents.","Scope includes security incidents that impact the EHR Solution."]
[1.7,"Information Security Incident Management Standard v1.8","The point of contact must send all incident tickets related to [the EHR Solution] to the incident response lead or team to review the incident ticket and any supporting information to verify whether or not an incident has occurred.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Assign an individual or group as a incident response lead.  In small organizations this may be an office manager.  This may also be the same individual as the point of contact. ","Scope includes security incidents that impact the EHR Solution."]
[1.8,"Information Security Incident Management Standard v1.8","The incident response lead or team must classify all actual incidents related to [the EHR Solution] according to severity (See Appendix A: Incident Severity and Priority Ratings for severity ratings).","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Determine how existing classifications used by the organization may align with the Severity ratings in the policy.","Scope includes security incidents that impact the EHR Solution."]
[1.9,"Information Security Incident Management Standard v1.8","The incident response lead or team must initiate an incident report related to [the EHR Solution]. (See Appendix B: Incident Report Details)","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"A security incident report template is available on request which includes the required fields and can be used to track this activity.","Scope includes security incidents that impact the EHR Solution.","A security incident reporting template is available on request which can be used to track the required incident details and can be used for notifications."]
["1.10","Information Security Incident Management Standard v1.8","HICs must ensure that their incident management process requires the incident response lead or team to notify [the EHR Solution] Program Office Privacy and Security Team by email or telephone and any affected HICs by the end of the next business day of confirmed incidents that are classified as Severity 1 or Severity 2 according to Appendix A: Incident Severity and Priority Ratings. At a minimum, the notification must contain the following elements:\n- The time and date of the reported incident\n- The name and contact information of the agent or Electronic Service Provider that reported the incident\n- Details about the reported incident, (e.g., type and how it was detected)\n- Any known or suspected impacts of the reported incident, and\n- Any actions undertaken to contain the incident either by the agent or Electronic Service Provider that reported the incident, the point of contact, or the incident response lead or team.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Ensure that the protocol includes notification to the Program Office according to the requirements. Privacy and Security incidents must be reported to the eHealth Ontario Enterprise Service Desk.","Scope includes security incidents that impact the EHR Solution."]
[1.1100000000000001,"Information Security Incident Management Standard v1.8","If an incident that originates at a HIC affects multiple HICs or [the EHR Solution], HICs must allow [the EHR Solution] Program Office to assume leadership of incident management activities if requested. ","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Ensure that your protocol recognizes where an incident may have involved multiple organizations. During the notification to eHealth Ontario (Program Office), indicate that the Program Office is suggested to take the lead.","Scope includes security incidents that impact the EHR Solution."]
[1.1200000000000001,"Information Security Incident Management Standard v1.8","The team that leads the incident management activities (i.e. HIC or [the EHR Solution] Program Office) must notify eHealth Ontario who will notify the Connecting Security Committee and the Applicable Oversight Body:\n- Within 72 hours of notification for any incident related to [the EHR Solution] and classified as a Severity 1 or\n- Within one week of notification for any incident related to [the EHR Solution] and classified as a Severity 2.","Must","HR","Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Ensure that your protocol includes notification to the require parties according to the timelines.\n\nNotification can be coordinated with the Program Office who will have the various contact information for the relevant committees. ","Scope includes security incidents that impact the EHR Solution."]
[1.1299999999999999,"Information Security Incident Management Standard v1.8","HICs should prioritize incidents related to [the EHR Solution] in accordance with their severity rating.","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Incidents need to be prioritized according to the severity.","Scope includes security incidents that impact the EHR Solution."]
[1.1399999999999999,"Information Security Incident Management Standard v1.8","The incident response lead or team must take steps to limit the scope and magnitude of an incident. Mitigation or containment activities may include:\n- Backing up the information system\n- Discontinuing operations\n- Changing passwords or modifying access control lists on the compromised information system, or\n- Restricting connectivity.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Determine possible scenarios within your organization and develop plans as to how you would contain those types of incidents.","Scope includes security incidents that impact the EHR Solution."]
[1.1499999999999999,"Information Security Incident Management Standard v1.8","HICs must remediate affected information systems so that they return to full and normal operations. Remediation activities may include:\n- Eradicating the cause of the incident (e.g., removing malware)\n- Restoring and validating the information system\n- Deciding when to restore operations, and\n- Monitoring information systems to verify normal operations without further information system or data compromise.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Predetermine based on possible scenarios how your organization would return to normal operations. ","Scope includes security incidents that impact the EHR Solution."]
[1.1599999999999999,"Information Security Incident Management Standard v1.8","HICs must investigate incidents related to [the EHR Solution] to identify the cause of the incident (e.g., by performing a root causes analysis.)","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Consider adopting a root cause analysis methodology to investigate incidents.  \n\nWiki article: https://en.wikipedia.org/wiki/Root_cause_analysis","Scope includes security incidents that impact the EHR Solution."]
[1.17,"Information Security Incident Management Standard v1.8","Once an incident related to [the EHR Solution] has been resolved (i.e., all remediation activities have been implemented and affected information systems and information technology have returned to full and normal operations), the incident response lead or team must complete the incident report. During longer investigations led by HICs, [the EHR Solution] Program Office or affected HICs may request status updates on the incident investigation in the interim.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Be familiar with the incident reporting requirements of the EHR Solution and include this in your protocol.  A template is available to capture the required information and is in a format that can be used for a final incident report.","Scope includes security incidents that impact the EHR Solution.","A security incident reporting template is available on request which can be used to track the required incident details and can be used for notifications."]
[1.18,"Information Security Incident Management Standard v1.8","HICs must archive their incident reports related to [the EHR Solution] for a minimum of 24 months.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Determine a secure location where your organization can save security incident reports.  This may include a SharePoint, file server, etc. where access control lists are applied and data is backed up and retained for the period required.  Where sensitive data is included in the report, consider encrypting the file contents using a strong password.","Scope includes security incidents that impact the EHR Solution."]
[1.19,"Information Security Incident Management Standard v1.8","HICs must provide [the EHR Solution] Program Office and impacted HICs with an incident report related to [the EHR Solution] within 72 hours of the incident report being requested.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Be familiar with the incident reporting requirements of the EHR Solution and include this in your protocol.   A template is available to capture the required information and is in a format that can be used for a final incident report","Scope includes security incidents that impact the EHR Solution.","A security incident reporting template is available on request which can be used to track the required incident details and can be used for notifications."]
["1.20","Information Security Incident Management Standard v1.8","The final incident reports should be reviewed by the Connecting Security Committee and if necessary the Applicable Oversight Body. eHealth Ontario will facilitate this review when the report is submitted by the HIC.","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Once reports are finalized by the site those can be communicated to eHealth Ontario. The Connecting Ontario Security Manager will facilitate presenting those reports to the governance bodies.","Scope includes security incidents that impact the EHR Solution."]
["1.21","Information Security Incident Management Standard v1.8","HICs should implement a mechanism to review their incidents related to [the EHR Solution], at a minimum, monthly to identify trends and to determine whether any preventative actions can be taken to reduce the likelihood of similar incidents from occurring in the future.","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Review incident reports to identify trends and take action to prevent reoccurrence. ","Scope includes security incidents that impact the EHR Solution."]
["1.22","Information Security Incident Management Standard v1.8","HICs should develop procedures for collecting evidence for the purposes of disciplinarily or legal action against agents or Electronic Service Providers. These procedures should require:\n- Forensics work to be performed on copies of the evidential material.\n- The creation of copies be witnessed\n- Details of the creation be logged, including:\n- When and where the copying process was executed\n- Who performed the copying activities, and\n- Which tools or programs were utilized for the copying process.\n- The integrity of all evidential material is protected.","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Consider processes that could be developed to facilitate the collection of evidence required to pursue disciplinary or legal action.","Scope includes security incidents that impact the EHR Solution."]
[2.1,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office must implement an information security incident (“incident”) management process that covers all phases of the incident management process:\n- Identification/Triage\n- Response\n- Recovery, and\n- Follow-up","Must",null,"Program Office"]
[2.2000000000000002,"Information Security Incident Management Standard v1.8","If at any point in the incident management process [the EHR Solution] Program realizes that the incident has resulted in a privacy breach, then the incident must be handled in accordance with the Privacy Breach Management Policy.","Must",null,"Program Office"]
[2.2999999999999998,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program must establish a point of contact to whom actual or suspected incidents are reported. Most often, the point of contact is a service desk.","Must",null,"Program Office"]
[2.4,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program must ensure that all its agents and Electronic Service Providers are aware of their responsibility to immediately report actual or suspected incidents to the established point of Contact.","Must",null,"Program Office"]
[2.5,"Information Security Incident Management Standard v1.8","The point of contact must generate an incident ticket for all reported incidents. An automated incident management system is recommended to support the recording of incidents. The incident ticket must contain the following elements:\n- The time and date of the reported incident\n- The name and contact information of the patient, HIC, Agent or Electronic Service Provider that reported the incident\n- Details about the reported incident, (e.g., type and how it was detected)\n- Any impacts of the reported incident, and\n- Any actions undertaken to contain the incident either by the agent or Electronic Service Provider that reported the incident or the point of contact.","Must",null,"Program Office"]
[2.6,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program must appoint an incident response lead or team who is responsible for initiating the triage, response, recovery and follow-up activities for all incidents. The incident response lead or team may be the same as the point of contact.","Must",null,"Program Office"]
[2.7,"Information Security Incident Management Standard v1.8","The point of contact must immediately send all incident tickets to the incident response lead or team.","Must",null,"Program Office"]
[2.8,"Information Security Incident Management Standard v1.8","The incident response lead or team must review the incident ticket and any supporting information to verify whether or not an incident has occurred.","Must",null,"Program Office"]
[2.9,"Information Security Incident Management Standard v1.8","The incident response lead or team must classify all actual incidents according to severity (See Appendix A: Incident Severity and Priority Ratings for severity ratings).","Must",null,"Program Office"]
[2.1,"Information Security Incident Management Standard v1.8","The incident response lead or team must initiate an incident report. (See Appendix B: Incident Report Details)","Must",null,"Program Office"]
[2.11,"Information Security Incident Management Standard v1.8","All completed or partially completed incident reports must be handled, at a minimum, in accordance with the protection requirements for information classified as Confidential.","Must",null,"Program Office"]
[2.12,"Information Security Incident Management Standard v1.8","If an incident that originates at a HIC affects multiple HICs or [the EHR Solution], [the EHR Solution] Program Office may assume leadership of the incident management activities.","Should",null,"Program Office"]
[2.13,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office must ensure that their incident management process requires the incident response lead or team to notify any affected HICs and/or eHealth Ontario by email by the end of the next business day of any incident that [the EHR Solution] Program classifies as a Severity 1 or Severity 2.\n\nAt a minimum, the notification must contain the following elements:\n- The time and date of the reported incident\n- The name and contact information of the agent or Electronic Service Provider that reported the incident\n- Details about the reported incident (e.g., type and how it was detected)\n- Any impacts of the reported incident, and\n- Any actions undertaken to contain the incident either by the agent or Electronic Service Provider that reported the incident, the point of contact, or the incident response lead or team.","Must",null,"Program Office"]
[2.14,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office must notify eHealth Ontario who will notify the Connecting Security Committee and the Applicable Oversight Body:\n- Within 72 hours of notification for any incident classified as a Severity 1, and\n- Within one week of notification for any incident classified as a Severity 2.","Must",null,"Program Office"]
[2.15,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office must prioritize all incidents in accordance with their severity and priority rating.","Must",null,"Program Office"]
[2.16,"Information Security Incident Management Standard v1.8","The incident response lead or team must take steps to limit the scope and magnitude of an incident. Mitigation or containment activities may include:\n- Backing up the information system\n- Discontinuing operations\n- Changing passwords or modifying access control lists on the compromised information system, and\n- Restricting connectivity.\n\nNOTE: Depending on the severity of an incident it may be necessary to activate [the EHR Solution] Program’s business continuity plans.","Must",null,"Program Office"]
[2.17,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office should create containment strategies for each major incident type, with criteria clearly documented to facilitate decision-making. Criteria for determining the appropriate strategy may include:\n- Potential damage to and theft of resources\n- Need for evidence preservation\n- Service availability (e.g., network connectivity, services provided to external parties)\n- Time and resources needed to implement the strategy\n- Effectiveness of the strategy (e.g., partial containment, full containment)\n - Duration of the solution (e.g., emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, permanent solution).\nNOTE: Depending on the severity and type an incident it may be necessary to activate [the EHR Solution] Program’s business continuity plans. Therefore, criteria should be defined to provide the incident response lead or team with guidance on when to notify business continuity personnel.","Should",null,"Program Office"]
[2.1800000000000002,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program must remediate all applicable information systems so that they return to full and normal operations. Remediation activities may include:\n- Eradicating the cause of the incident (e.g., removing malware)\n- Restoring and validating the information system\n- Deciding when to restore operations, and\n- Monitoring information systems to verify normal operations without further information system or data compromise.","Must",null,"Program Office"]
[2.19,"Information Security Incident Management Standard v1.8","[The EHR Solution]Program Office must investigate all incidents to identify the cause of the incident (e.g., by performing root cause analysis.)","Must",null,"Program Office"]
[2.2000000000000002,"Information Security Incident Management Standard v1.8","Once an incident has been resolved (i.e., all remediation activities have been implemented and affected information systems and information technology have returned to full and normal operations) the incident response lead or team must complete the incident report. During longer investigations, affected HICs may request status updates on the incident investigation in the interim.","Must",null,"Program Office"]
[2.21,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office must archive their incident reports for a minimum of 24 months.","Must",null,"Program Office"]
[2.2200000000000002,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office must provide participating HIC with any [the EHR Solution] incident reports within 72 hours of the request.","Must",null,"Program Office"]
[2.23,"Information Security Incident Management Standard v1.8","The final incident reports should be reviewed by the Connecting Security Committee and if necessary the Applicable Oversight Body. eHealth Ontario will facilitate this review when the report is submitted by [the EHR Solution] Program Office.","Should",null,"Program Office"]
[2.2400000000000002,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office should implement a mechanism to review all of their incidents, at a minimum, monthly to identify trends and to determine whether any preventative actions can be taken to reduce the likelihood of similar incidents from occurring in the future.","Should",null,"Program Office"]
[2.25,"Information Security Incident Management Standard v1.8","[The EHR Solution] Program Office should develop procedures for collecting evidence for the purposes of disciplinarily or legal action against agents or Electronic Service Providers. These procedures should require:\n- Forensics work to be performed on copies of the evidential material.\n- The creation of copies be witnessed\n\nDetails of the creation should be logged, including:\n- When and where the copying process was executed\n- Who performed the copying activities, and\n- Which tools or programs were utilized for the copying process.\n- The integrity of all evidential material is protected.","Should",null,"Program Office"]
[null,"Security Logging and Monitoring Standard v2.0",null,null,null,"null"]
[1.1000000000000001,"Security Logging and Monitoring Standard v2.0","HICs must log all HIC, agent, and Electronic Service Provider participation in the [the EHR Solution] , and must log system events/activities on their local identity provider technology and data contribution endpoints.  See Appendix A, Sources of Contents of Logs. ","Must","Administration","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should review the logging configurations on their systems in scope.  Logs required of the policy must be enabled.   Review appendix of standard.","Scope includes logging requirements in the policy on the systems in scope."]
[1.2,"Security Logging and Monitoring Standard v2.0","HICs should classify and protect logs in accordance with the highest level of information contained within the data contributor end point and identity provider service logs.","Should",null,"Data Contributor \nIdentity Provider "]
[1.3,"Security Logging and Monitoring Standard v2.0","HICs must log all activities of administrators and operators on their identity provider services and their data contribution endpoints as part of the general audit trail process.","Must","Administration","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should review the logging configurations on their systems in scope.  Logs required of the policy must be enabled.   Review appendix of standard.","Scope includes logging requirements in the policy on the systems in scope."]
[1.4,"Security Logging and Monitoring Standard v2.0","HICs must ensure that data contributor and identity provider services system logs, at a minimum and where relevant, contain the following information for each event/activity, consult the Identity Provider Standard for more specific logging requirements of the Identity Provider Service functions (e.g. registration, authentication, etc.):\n- Identifiers (as many as available) for the subject requesting the action (e.g., user ID, computer name, IP address, and MAC address).\n- Identifiers (as many as available) for the object the action was performed on (e.g., file names accessed, unique identifiers of records accessed in a database, IP address, and MAC address)\n- Date and time\n- The event activity (e.g., sign-on and sign-off)\n- Status of the security event activity (e.g., success or failure, denied or allowed)\n- Type of access (e.g., read, write, execute)\n- Alarms raised by access control and network monitoring systems.","Must","Administration","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should review the logging configurations on their systems in scope.  Logs required of the policy must be enabled.   Review appendix of standard.","Scope includes logging requirements in the policy on the systems in scope."]
[1.5,"Security Logging and Monitoring Standard v2.0","HICs must not filter their data contribution end point and identity provider service logs at the source.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Where logs are sent to a central source, these logs should be sent in full and allow the central source to filter any events not required.   Logs should not be supressed at the sources where they are created.","Scope includes logging requirements in the policy on the systems in scope."]
[1.6,"Security Logging and Monitoring Standard v2.0","HICs must synchronize their system clocks on their identity provider technology and data contribution endpoints to a centralized clock source. HICs must perform clock synchronization validation, at a minimum, daily to ensure on-going clock synchronization accuracy.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should ensure that an Network Time Protocol server is configured and that all systems are configured to set their date and time based on those servers.    Checks should be developed to ensure that the NTP and servers are current.","Scope includes logging requirements in the policy on the systems in scope."]
[1.7,"Security Logging and Monitoring Standard v2.0","HICs must implement controls to protect the confidentiality and integrity of all local identity provider technology and data contribution endpoints logs both in storage and during transmission.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations could off load system logs to a SYSLOG or SIEM solution to capture and retain logs.  \n\nOrganizations could also consider implementing Access Control Lists on the logs to ensure that they are kept confidential and keep their integrity.","Scope includes logging requirements in the policy on the systems in scope."]
[1.8,"Security Logging and Monitoring Standard v2.0","HICs must secure all access to local identity provider technology and data contribution endpoints logs.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations could off load system logs to a SYSLOG or SIEM solution to capture and retain logs.  \n\nOrganizations could also consider implementing Access Control Lists on the logs to ensure that they are kept confidential and keep their integrity.","Scope includes logging requirements in the policy on the systems in scope."]
[1.9,"Security Logging and Monitoring Standard v2.0","HICs should maintain a list of all agents or Electronic Service Providers who have authorized access to identity provider technology and data contribution endpoints logs. The list should contain:\n- Full name of the agent or Electronic Service Provider\n- ID that the agent or Electronic Service Provider uses to logically access the log, and\n- Name/type of log to which the agent or Electronic Service Provider has access.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1000000000000001,"Security Logging and Monitoring Standard v2.0","HICs should not configure local identity provider technology and data contribution endpoints logs to overwrite old data when the maximum log size limit has been reached.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1100000000000001,"Security Logging and Monitoring Standard v2.0","HICs must prohibit their agents and Electronic Service Providers with authorized access to local identity provider technology and data contribution endpoints logs from erasing or deactivating logs of their own activities.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1200000000000001,"Security Logging and Monitoring Standard v2.0","HICs must ensure that the management of their identity provider technology and data contribution endpoints log generation sources is logged and controlled via documented change control policies and procedures.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1299999999999999,"Security Logging and Monitoring Standard v2.0","HICs should implement automated mechanisms on their local identity provider technology and data contribution endpoints to consolidate logs to centralized log management servers.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1399999999999999,"Security Logging and Monitoring Standard v2.0","HICs should implement automated tools on their respective information systems to convert local identity provider technology and data contribution endpoints logs with different content and formats to a single standard format with consistent data field representations.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1499999999999999,"Security Logging and Monitoring Standard v2.0","HICs should monitor their local identity provider technology and data contribution endpoints logs to ensure that:\n- Log triggers are appropriately configured\n- Log triggers are not compromised\n- Faults are identified for further analysis and remediation steps, and\n- Identified faults are resolved or mitigated.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1599999999999999,"Security Logging and Monitoring Standard v2.0","HICs must be able to correlate their logs from their local identity provider technology and data contribution endpoints to assist in the detection and prevention of information and information system misuse or intrusion.","Must","Administration","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should send all logs to a central SYSLOG or SIEM solution. \n\nWhere those components are not available, the organization should ensure that they have manual processes to correlate logs when needed. This could involve having a incident management conference call with system admins and having an incident lead coordinate the team effort.","Scope includes logging requirements in the policy on the systems in scope."]
[1.17,"Security Logging and Monitoring Standard v2.0","HICs should implement automated correlation tools to look for patterns of events/activities across their local identity provider technology and data contribution endpoints logs.","Should",null,"Data Contributor \nIdentity Provider "]
[1.18,"Security Logging and Monitoring Standard v2.0","HICs should review their identity provider technology and data contribution endpoints logs, at a minimum, monthly.","Should",null,"Data Contributor \nIdentity Provider "]
[1.19,"Security Logging and Monitoring Standard v2.0","HICs should ensure that the logs of administrators and operators who support their local identity provider technology and data contribution endpoints are reviewed, at a minimum, quarterly.","Should",null,"Data Contributor \nIdentity Provider "]
[1.2,"Security Logging and Monitoring Standard v2.0","Segregation of duties should exist for identity provider technology and data contribution endpoints log reviews, e.g., someone other than the administrator should review the logs for the systems he/she manages.","Should",null,"Data Contributor \nIdentity Provider "]
[1.21,"Security Logging and Monitoring Standard v2.0","HICs should ensure that their logs relating to the data contribution endpoints and identity provider services are readily available online, at a minimum for the duration indicated in the Federation Identity Provider Standard and CPC Retention Policy. Logs must be available to facilitate investigations in a timely manner in accordance to standard.","Should",null,"Data Contributor \nIdentity Provider "]
[1.22,"Security Logging and Monitoring Standard v2.0","HICs must retain archived identity provider services and data contribution endpoints system logs for a minimum duration indicated in the Federation Identity Provider Standard and CPC Data Retention Policy whether the service is performed by the HIC, an agent or Electronic Service Provider.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should set up a SYSLOG system or SIEM to collect logs and events and retain them.","Scope includes logging requirements in the policy on the systems in scope."]
[1.23,"Security Logging and Monitoring Standard v2.0","HICs must archive their data contributor endpoint and identity provider service logs in a format that can be restored for as long as the data retention is required.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should ensure that recovery capabilities are considered when changing storage technology or solutions.","Scope includes logging requirements in the policy on the systems in scope."]
[1.24,"Security Logging and Monitoring Standard v2.0","HICs should label and store their data contributor and identity provider services archive logs in an organized manner for easy retrieval.","Should","Administration","Data Contributor \nIdentity Provider "]
[2.1,"Security Logging and Monitoring Standard v2.0","The EHR Solution] Program must log all information system events/activities on the [EHR Solution] found in Appendix A: Sources and Contents of Logs performed by Patients, HICs, Agent, and Electronic Service Provider with access to [the EHR Solution]. ","Must",null,"Program Office"]
[2.2000000000000002,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that their logging capabilities are enabled and operational at all times. [The EHR Solution] Program must configure their information systems in a manner such that they are disabled if logging is not operational.","Must",null,"Program Office"]
[2.2999999999999998,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that all logs are classified in accordance with the highest level of information contained within the logs.","Must",null,"Program Office"]
[2.4,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must log all activities of their information system administrators and information system operators as part of the general audit trail process.","Must",null,"Program Office"]
[2.5,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that all logs, at a minimum and where relevant, contain the following information for each event/activity:\n- Identifiers (as many as available) for the subject requesting the action (e.g., user ID, computer name, IP address, and MAC address)\n- Identifiers (as many as available) for the object the action was performed on (e.g., file names accessed, unique identifiers of records accessed in a database, IP address, and MAC address)\n- Date and time\n- The event activity (e.g., sign-on and sign-off)\n- Status of the security event activity (e.g., success or failure, denied or allowed)\n- Type of access (e.g., read, write, execute)\n- Alarms raised by access control and network monitoring systems.","Must",null,"Program Office"]
[2.6,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must not filter logs at the source.","Must",null,"Program Office"]
[2.7,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must synchronize their information system clocks to a centralized clock source. [The EHR Solution] Program must perform clock synchronization validation, at a minimum, daily to ensure on-going clock synchronization accuracy.","Must",null,"Program Office"]
[2.8,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must implement controls to protect the confidentiality and integrity of logs both in storage and during transmission.","Must",null,"Program Office"]
[2.9,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must restrict all access to logs based on the principles of least privileged and need-to-know.","Must",null,"Program Office"]
[2.1,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must maintain a list of all agents or Electronic Service Providers who have authorized access to logs. At minimum, the list must contain:\n- Full name of the agent or Electronic Service Provider\n- Work phone number of the agent or Electronic Service Provider\n- Work email address of the agent or Electronic Service Provider\n- ID that the agent or Electronic Service Provider uses to logically access the log, and\n- Name/type of log to which the agent or Electronic Service Provider has access.","Must",null,"Program Office"]
[2.11,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must not configure logs to overwrite old data when the maximum log size limit has been reached.","Must",null,"Program Office"]
[2.12,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must prohibit their agents and Electronic Service Providers with authorized access to logs from erasing or deactivating logs of their own activities.","Must",null,"Program Office"]
[2.13,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that the management of log generation sources is logged and controlled via documented change control procedures.","Must",null,"Program Office"]
[2.14,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program should implement automated mechanisms on their information systems to consolidate logs to centralized log management servers.","Should",null,"Program Office"]
[2.15,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program should implement automated tools on their information systems to convert logs with different content and formats to a single standard format with consistent data field representations.","Should",null,"Program Office"]
[2.16,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must monitor their logs to ensure that:\n- Log triggers are appropriately configured\n- Log triggers are not compromised\n- Faults are identified for further analysis and remediation steps, and\n- Identified faults are resolved or mitigated.","Must",null,"Program Office"]
[2.17,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program should implement automated analysis tools on their information systems to assist in the detection and prevention of information and information system misuse or intrusion.","Should",null,"Program Office"]
[2.1800000000000002,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program should implement automated correlation tools on their information systems to look for patterns of events/activities across multiple information systems.","Should",null,"Program Office"]
[2.19,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that automated alerts are triggered for unsuccessful authentication attempts.","Must",null,"Program Office"]
[2.2000000000000002,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must review their logs, at a minimum, monthly to detect anomalous events on the network or [The EHR Solution] agent or Electronic Service Provider behavior that is outside of standard or procedures, or to identify automated alerts generated that may indicate attacks or break-ins.","Must",null,"Program Office"]
[2.21,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that information system administrator and operator logs are reviewed, at a minimum, monthly.","Must",null,"Program Office"]
[2.2200000000000002,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that segregation of duties must exist for all log reviews, e.g., someone other than the information system administrator must review the logs for the information system he/she manages.","Must",null,"Program Office"]
[2.23,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that their logs relating to production data are readily available online, at a minimum, for six months.","Must",null,"Program Office"]
[2.2400000000000002,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must retain archived information system logs for a minimum duration as highlighted in the CPC  Retention Policy.","Must",null,"Program Office"]
[2.25,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must retain archived logs of HIC, agent, and Electronic Service Provider activities in accordance with [the EHR Solution] Retention Policy.","Must",null,"Program Office"]
[2.2599999999999998,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must ensure that logs related to backups are readily available online for the same period as logs related to production data.","Must",null,"Program Office"]
[2.27,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program must archive their logs in a format that can be restored for as long as the data retention is required.","Must",null,"Program Office"]
[2.2799999999999998,"Security Logging and Monitoring Standard v2.0","[The EHR Solution] Program should label and store their archive logs in an organized manner for easy retrieval.","Should",null,"Program Office"]
[2.29,"Security Logging and Monitoring Standard v2.0","Upon retention expiry, [the EHR Solution] Program must ensure that their logs are disposed of in accordance with the requirements defined in Information and Asset Management Standard.","Must",null,"Program Office"]
[null,"Local Registration Authority Practices Standard v1.8",null,null,null,"null"]
[1.1000000000000001,"Local Registration Authority Practices Standard v1.8","The Legally Responsible Person (LRP) must identify a named person(s), group(s), or role(s) that has the authority to act as a Sponsor.","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"The LRP must nominate a individual, group or role to be able to act as a Sponsor.  The Sponsor has the authority to grant individuals access to the solution in accordance to the policy.  A list of approved Sponsors should be documented and understood by all relevant parties within the organization. This could be included in a policy / procedure document.\n\n\nThe Sponsor Role, as defined in ONE ID, aligns with this requirement.  Refer to the ONE ID Policy for more information","Scope of user registered under this policy. For ConnectingOntario this includes the Administrative Portal and Provider Portal","ONE ID Policy"]
[1.2,"Local Registration Authority Practices Standard v1.8","The Sponsor must only provide access to [the EHR Solution] clinical components to Agents whose purpose of access is to collect PHI for providing or assisting in the provision of healthcare.\nExamples of end-users who may meet the criteria of providing healthcare or assisting in the provision of healthcare, may include, but are not limited to:\n- Regulated health professionals who see patients\n- Residents providing care to patients\n- Administrative staff who pull charts for physicians\n- Ward clerks who review results to flag abnormals for physicians","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"Data Sharing Agreements with HICs of the data indicate that access can only be provided for specific purposes. \n\nLRA training includes these messages.","Scope of user registered under this policy. For ConnectingOntario this includes the Administrative Portal and Provider Portal"]
[1.3,"Local Registration Authority Practices Standard v1.8","The Sponsor must only provide access to [the EHR Solution] administration components to Agents and Electronic Service Providers whose purpose of access is to:\n\n- Provide support for defined and permitted functionality within the administration roles of [the EHR Solution] (e.g. Privacy Officers, System Administrators Agents and Electronic Service Providers must not be granted access to functionality intended for those providing health care or assisting in the provision of health care (e.g. Clinicians).\n\nFor example, system administrators may require access to error queue management functionality to correct and process messages, privacy officers may require access to privacy reports to generate audit reports, data mapping specialists may require access to the terminology mapping functions to map codes and terminologies. These individuals must not be granted access to functionality intended for those providing healthcare or assisting in the provision of health care (e.g. clinicians).","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"IT or other support members  must only access the back end administrator portal or necessary systems.\n\nThese type of staff must not be provided access to the Clinician facing solution.\n\nData Sharing Agreements with HICs of the data indicate that access can only be provided for specific purposes. \n\nLRA training includes these messages.","Scope of user registered under this policy. For ConnectingOntario this includes the Administrative Portal and Provider Portal"]
[1.4,"Local Registration Authority Practices Standard v1.8","Sponsor’s must not provide access to [the EHR Solution] if access is requested for purposes other than providing or assisting in the provision of healthcare, e.g., providing access for the purposes of:\n- Program planning, evaluation, or monitoring\n- Risk or error management\n- Improving the quality of care, programs, and services\n- Education and training (unless the individual is a student or resident who requires access to provide care)\n- For processing payments.","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"\nData Sharing Agreements with HICs of the data indicate that access can only be provided for specific purposes. \n\nLRA training includes these messages.","Scope of user registered under this policy. For ConnectingOntario this includes the Administrative Portal and Provider Portal"]
[1.5,"Local Registration Authority Practices Standard v1.8","Sponsor’s must not provide access to [the EHR Solution] if access is requested for the purpose of research.","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"\nData Sharing Agreements with HICs of the data indicate that access can only be provided for specific purposes. \n\nLRA training includes these messages.","Scope of user registered under this policy. For ConnectingOntario this includes the Administrative Portal and Provider Portal"]
[1.6,"Local Registration Authority Practices Standard v1.8","If an agent or Electronic Service Provider has multiple roles, e.g., is both a clinician and a risk manager, the Sponsor may assign that person with access to [the EHR Solution] for the purposes of collecting PHI for providing or assisting in the provision of health care and must ensure that the end user understands their permissions and obligations.","Must",null,"Data Contributor \nIdentity Provider \nViewer \nProgram Office",null,null,null,null,null,"Data Sharing Agreements with HICs of the data indicate that access can only be provided for specific purposes. \n\nLRA and Clinician training includes messages as to what purpose of access is appropriate.","Scope of user registered under this policy. For ConnectingOntario this includes the Administrative Portal and Provider Portal"]
[1.7,"Local Registration Authority Practices Standard v1.8","The Sponsor must remove entitlements that are no longer needed by the agent, e.g. the agent no longer works for the HIC","Must"]
[null,"Network and Operations Standard v2.0",null,null,null,"null"]
[1.1000000000000001,"Network and Operations Standard v2.0","HICs must maintain an inventory of assets related to their identity provider services and data contribution endpoints.","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations need to keep an inventory of their systems.  \n\nThis may be maintained in configuration management system or a spreadsheet under the authority of a dedicated person or role.","Scope includes assets under scope of assessment."]
[1.2,"Network and Operations Standard v2.0","HICs must document and maintain network diagrams of all direct connections to their identity provider services and data contribution endpoints. Network diagrams may include:                           - Physical and logical topologies\n- Network device configuration\n- Gateways to external networks\n- Connected network devices","Must",null,"Data Contributor \nIdentity Provider "]
[1.3,"Network and Operations Standard v2.0","HICs must implement network zones and manage these network zones in a manner that observes the separation of different computing environments. The segregation of networks may be based on criteria, such as:                                                       \n- The classification of information transmitted on the network.\n- The level of assurance required.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"An organization should ensure that networking devices are deployed to segregate the HICs internal network from the Internet or other untrusted networks.   Typically a firewall would be deployed with configurations to protect the internal computers from threats.\n\nAn organizations may offer a \"guest\" network for its Patients or other visitors. This should be separate from the HICs business network to prevent unauthorized individuals from accessing the HICs network.\n\nFurther separation may be desirable, for example if office space is sub-contracted to another entity the network should also be separate to ensure a trusted environment is used to access the EHR solution. ","Scope includes assets under scope of assessment."]
[1.4,"Network and Operations Standard v2.0","HICs must control traffic between networks zones by using a security gateway at the zones’ perimeter.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Network zones (e.g. guest network, HIC office network) should be separated by a security gateway which typically is a Firewall with specific rules configured to protect the network.","Scope includes assets under scope of assessment."]
[1.5,"Network and Operations Standard v2.0","HICs must configure their security gateways to filter traffic to or from network zones that contain their identity provider services and data contribution endpoints by denying all network traffic (inbound or outbound) by default and failing secure where availability requirements permit.","Must",null,"Data Contributor \nIdentity Provider "]
[1.6,"Network and Operations Standard v2.0","HICs should implement a process to review security gateway configurations at least annually. The process should ensure the:\n- Review of the rule sets on their security gateways\n- Removal of expired or unnecessary rules\n- Resolution of conflicting rules, and\n- Removal of unused or duplicate objects, e.g. network or computer systems.","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"On an annual basis, the network configuration should be reviewed by a qualified individual to ensure that the network rules (permitted / denied) are legitimate.   Unnecessary, expired or conflicting rules should be analyzed and adjusted. Duplicate or obsolete network objects (e.g. computers) should be removed.  These control will enhance the integrity of the network. ","Scope includes assets under scope of assessment."]
[1.7,"Network and Operations Standard v2.0","Where possible, HICs must disable unnecessary services, protocols, and ports on their identity provider services and data contribution endpoints. This must be in place when new systems and major upgrades to legacy systems are implemented. Alternate configurations are acceptable where perimeter systems implement access control lists or firewall rules to limit access to services on legacy systems that are sensitive to upgrades.                                                                     HICs should document and maintain justification for the use of all services, protocols, and ports allowed, including security features implemented for services, protocols, and ports considered to be insecure (e.g., FTP, Telnet, POP3, IMAP, and SNMP). HICs should reference Vendor specifications and industry benchmarks such as the Center for Internet Security (CIS).","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"System hardening will reduce the number of services, protocols and ports that are running on a system.  Any of these could be a threat vector that could be used to exploit the system.  Reducing these limits the threat exposure.\n\nOrganizations should consult with their vendor to determine acceptable practices.  They may also review industry frameworks such as the Centre for Internet Security for hardening guidelines.\n\nThese changes should first be tested in a development environment.  Where there is apprehension to make changes to the actual system, the organization should consider perimeter controls to reduce the threat vectors.","Scope includes assets under scope of assessment."]
[1.8,"Network and Operations Standard v2.0","Where possible, HICs must implement network restrictions that secure participation in [the EHR Solution] data contribution endpoint services and identity provider services administrative functionality to explicitly authorized services or workstations. This must be in place when new systems and major upgrades to legacy systems are implemented.","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations should deploy various zoning to segregate systems.   Often a management zone is created for system administrators to access support systems. The system admins log into a Terminal Server in the management zone and then access support systems in various VLANs or network zones.","Scope includes assets under scope of assessment."]
[1.9,"Network and Operations Standard v2.0","Where possible, HICs must harden all their identity provider services and data contribution endpoints prior to being implemented in the production environment. This must be in place when new systems and major upgrades to legacy systems are implemented. Alternate configurations are acceptable where perimeter systems implement access control lists or firewall rules to limit access to services on legacy systems that are sensitive to upgrades. Operating systems and applications must be upgraded or deprecated before end of life.","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"System hardening will reduce the number of services, protocols and ports that are running on a system.  Any of these could be a threat vector that could be used to exploit the system.  Reducing these limits the threat exposure.\n\nOrganizations should consult with their vendor to determine acceptable practices.  They may also review industry frameworks such as the Centre for Internet Security for hardening guidelines.\n\nThese changes should first be tested in a development environment.  Where there is apprehension to make changes to the actual system, the organization should consider perimeter controls to reduce the threat vectors.","Scope includes assets under scope of assessment."]
["1.10","Network and Operations Standard v2.0","Where possible, HICs must remove unnecessary functionality (e.g., such as drivers, features, subsystems, file systems) on their identity provider services and data contribution endpoints. This must be in place when new systems and major upgrades to legacy systems are implemented. Alternate configurations are acceptable where perimeter systems implement access control lists or firewall rules to limit access to services on legacy systems that are sensitive to upgrades.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"System hardening will reduce the number of services, protocols and ports that are running on a system.  Any of these could be a threat vector that could be used to exploit the system.  Reducing these limits the threat exposure.\n\nOrganizations should consult with their vendor to determine acceptable practices.  They may also review industry frameworks such as the Centre for Internet Security for hardening guidelines.\n\nThese changes should first be tested in a development environment.  Where there is apprehension to make changes to the actual system, the organization should consider perimeter controls to reduce the threat vectors.","Scope includes assets under scope of assessment."]
[1.1100000000000001,"Network and Operations Standard v2.0","HICs must implement intrusion detection and prevention mechanisms (e.g., host intrusion detection/prevention systems, network intrusion detection/prevention systems, SIEMs, or automated alerting) for identity provider services, data contribution endpoints, end user devices participating the EHR Solution. ","Must",null,"Data Contributor \nIdentity Provider "]
[1.1200000000000001,"Network and Operations Standard v2.0","HICs should protect their intrusion detection and prevention sensors (i.e., the hardware used to identify unauthorized activity in network traffic) against attack, for example, by using a network tap to hide the presence of the sensor.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1299999999999999,"Network and Operations Standard v2.0","HICs must update intrusion detection and prevention software within defined timescales and at the recommendation of the vendor (e.g., on discovery of a sever vulnerability).","Must",null,"Data Contributor \nIdentity Provider "]
[1.1399999999999999,"Network and Operations Standard v2.0","HICs must configure their intrusion detection and prevention software to provide an alarm or alert when suspicious activity is detected or prevented.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1499999999999999,"Network and Operations Standard v2.0","HICs must configure thresholds for alarms and alerts to identify possible intrusion detection or prevention events or violations of their information security policies.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1599999999999999,"Network and Operations Standard v2.0","HICs must respond to information security incidents identified by intrusion detection and prevention mechanisms in accordance with their information security incident handling process.","Must",null,"Data Contributor \nIdentity Provider "]
[1.17,"Network and Operations Standard v2.0","HICs must implement malware detection and repair software or equivalent solution on their identity provider services and data contribution endpoints to protect from malicious code. Alternative solutions may include application whitelisting or utilization of thin client implementations which restrict writable capabilities. Questions regarding the appropriateness of alternative solution should be directed to the Security Lead for [the EHR Solution] which can be put forward to the Connecting Security Committee.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Anti-malware software should be installed on systems to protect them from associated threats.","Scope includes assets under scope of assessment."]
[1.18,"Network and Operations Standard v2.0","HICs must keep their virus definition files for their identity provider services and data contribution endpoints up-to-date within one week.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Anti-malware software needs to be kept up to date.  Typically systems would report into the central console to receive their definitions from that system. This can be configured to automatically update.","Scope includes assets under scope of assessment."]
[1.19,"Network and Operations Standard v2.0","HICs must  keep their malware detection and repair software up-to-date.","Must",null,"Viewer",null,null,null,null,null,"Malware detection and repair software (e.g. Antivirus software) should be kept up to date to best be able to detect malicious software that may be able to compromise your network.  Often this software can be configured to check for updates automatically and scan the HIC approved tool.","Scope includes assets under scope of assessment."]
[1.2,"Network and Operations Standard v2.0","HICs must program their malware detection and repair software on their identity provider services and data contribution endpoints to run at regular intervals.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Anti-malware software is typically configured to run in real time to detect and isolate malware that is impacting the system.  Where performance impacts are noticed, the software can be tuned to exclude specific files or run on an alternate schedule.  Exclusions and changes to an always on schedule should be evaluated for effectiveness.","Scope includes assets under scope of assessment."]
[1.21,"Network and Operations Standard v2.0","HICs should implement a vulnerability management process to address the following:\n- Scanning and monitoring\n- Risk assessment, and\n- Remediation","Should",null,"Data Contributor \nIdentity Provider "]
[1.22,"Network and Operations Standard v2.0","HICs should a perform vulnerability and configuration scans on their identity provider services and data contribution end points that interface with [the EHR Solution] every 6 months.","Should",null,"Data Contributor \nIdentity Provider "]
[1.23,"Network and Operations Standard v2.0","HICs should define timelines to react to the notification of potentially relevant vulnerabilities.","Should",null,"Data Contributor \nIdentity Provider "]
[1.24,"Network and Operations Standard v2.0","HICs must assess all risks posed by vulnerabilities they have identified on their identity provider services and data contribution endpoints.","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations need to analyze risk related to vulnerabilities discovered on their systems.  Often new vulnerabilities will be announced through security advisories by software vendors.  Organizations should task a group to oversee this function and review security advisories as they are released and determine mitigation strategies.\n\nOn going infrastructure system scans are a good method to ensure that vulnerabilities have been discovered and remediated.  Products such as Nessus, Qualys, or others can scan systems and report findings.\n\nOrganizations must also consider other vulnerabilities just which are not technical in nature, for example, changing business processes, or entering in new relationships with suppliers can introduce new vulnerabilities.","Scope includes assets under scope of assessment.  Consider both technical, physical and business processes."]
[1.25,"Network and Operations Standard v2.0","If a patch is available, HICs must assess the risks associated with installing the patch vs not installing the patch on their identity provider services and data contribution endpoints to mitigate high-risk vulnerabilities in a timely manner.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"A patch management function should be operational with the organization.  This would assign a specific group to review the new patches, make an assessment of the risk and implementation risks and then recommend a decision to the appropriate accountable body.","Scope includes assets under scope of assessment."]
[1.26,"Network and Operations Standard v2.0","Where possible, HICs must test and evaluate all patches prior to installation on their identity provider services and data contribution endpoints to ensure they are effective and do not result in side effects that the HIC cannot tolerate.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Test environments should be used to validate that patches do not have an adverse effect on the systems.  Organizations should develop a standard set of tests to be completed to validate changes.  Enhancing these tests may be necessary where a system change is more significant.","Scope includes assets under scope of assessment."]
[1.27,"Network and Operations Standard v2.0","If a HIC decides not to apply a patch on their identity provider services and data contribution endpoints, the HIC must document the decision and should make the appropriate conforming changes to inventory records and disaster recovery plans.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"The patch management group accountable for analyzing patches must document decision made by the group and accountable body.","Scope includes assets under scope of assessment."]
[1.28,"Network and Operations Standard v2.0","If no patch is available or the decision is made not to patch their identity provider services and data contribution endpoints, HICs must consider implementing compensating controls to reduce the risks posed by the vulnerability. Controls may include:                           - Turning off services or capabilities related to the vulnerability\n- Adapting or adding access controls (e.g., firewalls at the network border)\n- Increasing monitoring to detect or prevent actual attacks","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Where a patch is not applied or its installation is delayed, the organization needs to consider what compensating controls could be implemented.   Often the vendor advisory will give an indication as to what mitigations may be appropriate.    Other times an organization may need to consider the mitigation in the context of its business operations.","Scope includes assets under scope of assessment."]
[1.29,"Network and Operations Standard v2.0","HICs should update their identity provider services and data contribution endpoints configurations or baseline security configuration standards as appropriate, to improve their effectiveness based on the results of vulnerability and configuration scans.","Should","CISO","Data Contributor \nIdentity Provider "]
[1.3,"Network and Operations Standard v2.0","HICs must ensure that all changes to their identity provider services and data contribution endpoints follow their defined change control procedures.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations need to have a mechanism to manage changes to the systems.  Often a change or release management group will be accountable to overseeing changes to systems.   This type of oversight should be implemented, it may be a single individual accountable for managing / approving changes or a larger structure.","Scope includes assets under scope of assessment."]
[1.31,"Network and Operations Standard v2.0","HICs should back up their relevant information systems.","Should",null,"Data Contributor \nIdentity Provider "]
[1.32,"Network and Operations Standard v2.0","HICs must secure all backups containing PHI. Encryption must be used when physically transferring data between sites.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Backups of Identity Provider and Data Contribution systems may include Personal Information or Personal Health Information.  Consult your back up system infrastructure and determine if encryption functionality can be implemented on back up media that is transferred outside of the organization.","Scope includes assets under scope of assessment."]
[1.33,"Network and Operations Standard v2.0","HICs should regularly test backup media to ensure that they can be relied upon for emergency use when necessary. Whole system restores should be tested annually.","Should",null,"Data Contributor \nIdentity Provider "]
[1.34,"Network and Operations Standard v2.0","HICs should regularly test their restoration procedures to ensure that they are effective and that they can be completed within the time allotted in their operational procedures for recovery. Restoration procedures should be tested annually.","Should","CISO","Data Contributor \nIdentity Provider "]
[2.1,"Network and Operations Standard v2.0","[The EHR Solution] Program must maintain an inventory of all their physical information technologies that comprise [the EHR Solution]. The inventory of assets must include, but is not limited to:\n- Type of asset.\n- Information technology owner, where applicable.\n- Location of the information technology (and information technology owner, where applicable).\n- Backup information.","Must",null,"Program Office"]
[2.2000000000000002,"Network and Operations Standard v2.0","[The EHR Solution] Program must document and maintain network diagrams of all direct connections to [the EHR Solution]. Network diagrams should include, but are not limited to:\n- Physical and logical topologies\n- Network device configuration\n- Gateways to external networks\n- Connected network devices","Must",null,"Program Office"]
[2.2999999999999998,"Network and Operations Standard v2.0","[The EHR Solution] Program must document and maintain operating procedures for [the EHR Solution]. The operating procedures should specify the instructions for the detailed execution of jobs, such as performing backups, system restart and recovery procedures, and error handling.","Must",null,"Program Office"]
[2.4,"Network and Operations Standard v2.0","[The EHR Solution] Program must restrict all participation in system documentation and operating procedures based on the principles of least-privileged and need-to-know.","Must",null,"Program Office"]
[2.5,"Network and Operations Standard v2.0","[The EHR Solution] Program should segregate duties and areas of responsibility for managing their network to reduce opportunities for unauthorized or unintentional access, collection, use, disclosure, transfer, modification or disposal.","Should",null,"Program Office"]
[2.6,"Network and Operations Standard v2.0","[The EHR Solution] Program must implement network zones and manage these network zones in a manner that observes the separation of different computing environments. The segregation of networks should be based on criteria, such as:\n- The classification of information transmitted on the network.\n- The level of assurance required.","Must",null,"Program Office"]
[2.7,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that networks are segregated, logically or physically, between [the EHR Solution], HIC information systems, and public networks.","Must",null,"Program Office"]
[2.8,"Network and Operations Standard v2.0","[The EHR Solution] Program must control traffic between networks zones by using a security gateway at its perimeter.","Must",null,"Program Office"]
[2.9,"Network and Operations Standard v2.0","[The EHR Solution] Program must configure their security gateways to filter traffic between network zones by denying all network traffic (inbound or outbound) by default and failing secure where availability requirements permit.","Must",null,"Program Office"]
[2.1,"Network and Operations Standard v2.0","[The EHR Solution] Program should implement a process to review security gateway configurations at least annually. The process should ensure the:\n- Review of the rule sets on their security gateways\n- Removal of expired or unnecessary rules\n- Resolution of conflicting rules, and\n- Removal of unused or duplicate objects, e.g. network or computer systems.","Should",null,"Program Office"]
[2.11,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that authentication and authorization processes are in place on [the EHR Solution] network before access to [the EHR Solution] is granted.","Must",null,"Program Office"]
[2.12,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that all connectivity to [the EHR Solution] is secured to ensure the confidentiality and integrity of PHI that is transmitted (e.g., through the use of Transport Layer Security (TLS), virtual private network (VPN) tunnels, terminal services, etc.).","Must",null,"Program Office"]
[2.13,"Network and Operations Standard v2.0","[The EHR Solution] Program must require a [the EHR Solution]-approved identifier (e.g., digital certificate, MAC address, IP address) to be used to indicate whether an data contribution endpoint or identity provider service asset is permitted to connect to the network and which network zone the asset is permitted to connect. Considerations should be made for other assets connecting to [the EHR Solution].","Must",null,"Program Office"]
[2.14,"Network and Operations Standard v2.0","[The EHR Solution] Program must disable all unnecessary services, protocols, and ports on their information systems. [The EHR Solution] Program should document and maintain justification for the use of all services, protocols, and ports allowed, including security features implemented for services, protocols, and ports considered to be insecure (e.g., FTP, Telnet, POP3, IMAP, and SNMP). [The EHR Solution] Program should reference Vendor specifications and industry benchmarks such as the Center for Internet Security (CIS).","Must",null,"Program Office"]
[2.15,"Network and Operations Standard v2.0","[The EHR Solution] must terminate all direct inbound and outbound external connections in a semi-trusted network zone (e.g. a demilitarized zone (DMZ)).","Must",null,"Program Office"]
[2.16,"Network and Operations Standard v2.0","[The EHR Solution] must ensure that all information system components that store information classified as Internal or higher are located in an internal network zone, segregated from the DMZ and other untrusted networks.","Must",null,"Program Office"]
[2.17,"Network and Operations Standard v2.0","[The EHR Solution] must disable split tunnelling on any information system or information technology with access to [the EHR Solution], except for networking devices (e.g., routers, firewalls).","Must",null,"Program Office"]
[2.1800000000000002,"Network and Operations Standard v2.0","[The EHR Solution] should close a network connection once the established unsuccessful attempt threshold has been reached.","Should",null,"Program Office"]
[2.19,"Network and Operations Standard v2.0","[The EHR Solution] should implement network routing controls based on positive source and destination address checking mechanisms.","Should",null,"Program Office"]
[2.2000000000000002,"Network and Operations Standard v2.0","[The EHR Solution] must harden all their information systems prior to implementation into the production environment.","Must",null,"Program Office"]
[2.21,"Network and Operations Standard v2.0","[The EHR Solution] must remove all unnecessary functionality (e.g., such as drivers, features, subsystems, file systems, and unnecessary web servers).","Must",null,"Program Office"]
[2.2200000000000002,"Network and Operations Standard v2.0","[The EHR Solution] must implement information security features for any required services, protocols or daemons that are considered to be insecure (e.g., use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.).","Must",null,"Program Office"]
[2.23,"Network and Operations Standard v2.0","[The EHR Solution] should only implement one primary function per server to prevent functions that require different security levels from co-existing on the same server (e.g., web servers and database servers should be set-up on separate servers). Where functions share the same security level it may be acceptable to run more than one function per server. Where virtualization technologies are in use, only one primary function per virtual system component should be implemented.","Should",null,"Program Office"]
[2.2400000000000002,"Network and Operations Standard v2.0","[The EHR Solution] Program must install personal firewall software on their agent’s or Electronic Service Provider’s workstation, laptop, and where technically feasible other mobile devices, with direct connectivity to the internet and [the EHR Solution].","Must",null,"Program Office"]
[2.25,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that mobile workstations (e.g. notebooks, laptops, etc.) that have a documented business requirement to work with data extracts containing PHI have full-disk or partial encryption securely installed. Full disk encryption is the preferred method however containerized implementations of encryption on directories or specific location are also acceptable. Implementations where PHI remains on managed servers in a protected data centre (i.e. Citrix) do not require encryption at rest.","Must",null,"Program Office"]
[2.2599999999999998,"Network and Operations Standard v2.0","[The EHR Solution] Program must implement intrusion detection and prevention mechanisms (e.g., host intrusion detection/prevention systems and network intrusion detection/prevention systems) on their information systems and networks.","Must",null,"Program Office"]
[2.27,"Network and Operations Standard v2.0","[The EHR Solution] Program must protect their intrusion detection and prevention sensors (i.e., the hardware used to identity unauthorized activity in network traffic) against attack, for example, by using a network tap to hide the presence of the sensor.","Must",null,"Program Office"]
[2.2799999999999998,"Network and Operations Standard v2.0","[The EHR Solution] Program must update intrusion detection and prevention software within defined timescales and at the recommendation of the vendor (e.g., on discovery of a sever vulnerability).","Must",null,"Program Office"]
[2.29,"Network and Operations Standard v2.0","[The EHR Solution] Program must configure their intrusion detection and prevention software to provide an alarm or alert when suspicious activity is detected or prevented.","Must",null,"Program Office"]
[2.2999999999999998,"Network and Operations Standard v2.0","[The EHR Solution] Program must configure thresholds for alarms and alerts to identify possible intrusion detection or prevention events, or violations of [the EHR Solution] information security policies and its associated procedures.","Must",null,"Program Office"]
[2.31,"Network and Operations Standard v2.0","[The EHR Solution] Program must respond to information security incidents identified by intrusion detection and prevention mechanisms in accordance with their information security incident handling process.","Must",null,"Program Office"]
[2.3199999999999998,"Network and Operations Standard v2.0","[The EHR Solution] Program must implement malware detection and repair software or equivalent solution on all workstations (e.g., desktops, laptops, etc.) and servers. Alternative solutions may include application whitelisting or utilization of thin client implementations which restrict writable capabilities. Questions regarding the appropriateness of alternative solution should be directed to the Security Lead for [the EHR Solution] which can be put forward to the Connecting Security Committee.","Must",null,"Program Office"]
[2.33,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that virus definition files remain up-to-date within a week.","Must",null,"Program Office"]
[2.34,"Network and Operations Standard v2.0","[The EHR Solution] Program must keep all their malware detection and repair software up-to-date.","Must",null,"Program Office"]
[2.35,"Network and Operations Standard v2.0","[The EHR Solution] Program should automate virus definition file updates and a verification capability should be in place to ensure that workstations and servers have been properly updated. Where virus definition file updates are not automated, these workstations or servers must be identified and updated manually.","Should",null,"Program Office"]
[2.36,"Network and Operations Standard v2.0","[The EHR Solution] Program must program their malware detection and repair software to run at regular intervals, at a minimum, weekly unless scanning is performed in real time. [The EHR Solution] Program must disconnect infected information systems and information technology from the network until it has been verified that they are malware-free.","Must",null,"Program Office"]
[2.37,"Network and Operations Standard v2.0","[The EHR Solution] Program must implement malware detection and repair software to scan electronic or optical media, incoming files, electronic mail attachments, and downloads for malware before their use. These checks may be carried out at different places, such as electronic mail servers, and desktop computers.","Must",null,"Program Office"]
[2.38,"Network and Operations Standard v2.0","[The EHR Solution] Program must implement a vulnerability management process to address:\n- Scanning and monitoring\n- Risk assessment, and\n- Remediation","Must",null,"Program Office"]
[2.39,"Network and Operations Standard v2.0","[The EHR Solution] Program must monitor their information systems to identify new vulnerabilities.","Must",null,"Program Office"]
[2.4,"Network and Operations Standard v2.0","[The EHR Solution] Program must perform vulnerability and configuration scans on [the EHR Solution] at a minimum, quarterly to determine the effectiveness of the implemented operational and technical security controls.","Must",null,"Program Office"]
[2.41,"Network and Operations Standard v2.0","[The EHR Solution] program must perform penetration tests, at a minimum, annually on all their internet-facing applications that provide access to PHI to ensure that these applications do not expose [the EHR Solution] to unknown threats.","Must",null,"Program Office"]
[2.42,"Network and Operations Standard v2.0","Penetration tests on internet-facing applications must include web-application testing techniques executed against a documented set of industry standards such as the OWASP Top 10, to identify weakness that are unique to web-based applications (such as SQL/LDAP injection, cross-site scripting, session token attacks and URL forgery), and must be subject to rigorous external content review.","Must",null,"Program Office"]
[2.4300000000000002,"Network and Operations Standard v2.0","Configuration scans should be executed to ensure compliance with the approved baseline security configuration standard.","Should",null,"Program Office"]
[2.44,"Network and Operations Standard v2.0","Where possible, [the EHR Solution] program should incorporate findings from vulnerability and security configuration scans in threat risk assessments to provide an accurate risk overview of [the EHR Solution].","Should",null,"Program Office"]
[2.4500000000000002,"Network and Operations Standard v2.0","[The EHR Solution] program must ensure that all risks posed by vulnerabilities are identified on their information systems and their remediation plans are assessed by a security analyst with independence to the operational teams.","Must",null,"Program Office"]
[2.46,"Network and Operations Standard v2.0","[The EHR Solution] program must ensure that all vulnerabilities identified on their information systems are remediated within a defined timeline or must have the risk posed by the vulnerability formally accepted if the decision is made not to remediate.","Must",null,"Program Office"]
[2.4700000000000002,"Network and Operations Standard v2.0","[The EHR Solution] Program should maintain a list of vulnerability and configuration scanning tools which are approved by [the EHR Solution] Security Lead.","Should",null,"Program Office"]
[2.48,"Network and Operations Standard v2.0","[The EHR Solution] Program must define timelines to react to the notification of potentially relevant vulnerabilities.","Must",null,"Program Office"]
[2.4900000000000002,"Network and Operations Standard v2.0","[The EHR Solution] Program must implement a security patch management process to ensure that available patches are identified, assessed and, where feasible, deployed. The security patch management process may be a part of a general patch management process.","Must",null,"Program Office"]
[2.5,"Network and Operations Standard v2.0","If a patch is available, [the EHR Solution] Program must assess the risks associated with installing the patch (i.e. the risks posed by the vulnerability must be compared with the risk of installing the patch).","Must",null,"Program Office"]
[2.5099999999999998,"Network and Operations Standard v2.0","Where possible, [the EHR Solution] Program must test and evaluate all patches prior to installation to ensure they are effective and do not result in side effects that cannot be tolerated.","Must",null,"Program Office"]
[2.52,"Network and Operations Standard v2.0","If the decision is made not to patch, then [the EHR Solution] Program must document the decision and make the appropriate conforming changes to inventory records and disaster recovery plans.","Must",null,"Program Office"]
[2.5299999999999998,"Network and Operations Standard v2.0","If no patch is available, or the decision is made not to patch, [the EHR Solution] Program must consider implementing compensating controls to reduce the risks posed by the vulnerability. Controls may include:\n- Turning off services or capabilities related to the vulnerability\n- Adapting or adding access controls (e.g., firewalls at the network border)\n- Increasing monitoring to detect or prevent actual attacks","Must",null,"Program Office"]
[2.54,"Network and Operations Standard v2.0","[The EHR Solution] Program must review and update their information system configurations or baseline security configuration standards as appropriate, to improve their effectiveness based on the results of vulnerability scans and changing industry practices.","Must",null,"Program Office"]
[2.5499999999999998,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that all changes to networks and information systems follow their defined change control procedures.","Must",null,"Program Office"]
[2.56,"Network and Operations Standard v2.0","[The EHR Solution] Program must back up [the EHR Solution] so that it may be recovered following a disaster or media failure.","Must",null,"Program Office"]
[2.57,"Network and Operations Standard v2.0","At a minimum, [the EHR Solution] Program must ensure that [the EHR Solution] is backed up in accordance to established and approved recovery time objectives (RTO) and recovery point objectives (RPO).","Must",null,"Program Office"]
[2.58,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that backups are stored in a remote location, at a sufficient distance to escape any damage from a disaster at the main site.","Must",null,"Program Office"]
[2.59,"Network and Operations Standard v2.0","[The EHR Solution] Program must secure all backups containing PHI. Encryption must be used when physically transferring data between sites.","Must",null,"Program Office"]
[2.6,"Network and Operations Standard v2.0","[The EHR Solution] Program must ensure that backup media and information systems are protected by physical and environmental controls equivalent to the physical and environmental controls applied at the main site.","Must",null,"Program Office"]
[2.61,"Network and Operations Standard v2.0","[The EHR Solution] Program must test backup media on a regular basis and backup failures need to be tracked, reported and remediated.","Must",null,"Program Office"]
[2.62,"Network and Operations Standard v2.0","[The EHR Solution] Program must regularly test its restoration procedures to ensure that they are effective and that they can be completed within the time allotted in their operational procedures for recovery. At a minimum, restoration procedures must be tested, at a minimum, annually.","Must",null,"Program Office"]
[2.63,"Network and Operations Standard v2.0","The retention period for data archives of [the EHR Solution] shall be determined by the record retention requirements of the information they contain, and in accordance to any legal or regulatory requirements and in accordance to the Connecting Privacy Committee Harmonized Retention and Destruction Policy.","Must",null,"Program Office"]
[null,"Physical Security Standard v1.8",null,null,null,"null"]
[1.1000000000000001,"Physical Security Standard v1.8","HICs must implement physical security perimeters to protect identity provider services and data contribution endpoints from unauthorized physical access and environmental damage.","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations need to protect their infrastructure by deploying it in locations that are not accessible by unauthorized individuals.   \n\nEnvironmental controls must be put in place to protect infrastructure.","Scope includes assets under scope of assessment."]
[1.2,"Physical Security Standard v1.8","HICs must ensure that highly sensitive facilities (i.e., buildings or storage areas that house identity provider services and data contribution endpoints) are protected against unauthorized physical access. Methods for preventing physical access may include:\n- Fitting vulnerable doors and windows with locks or bolts\n- Installing and monitoring closed-circuit television (CCTV)\n- Employing security guards, and\n- Installing intruder detection systems on external doors and testing accessible windows regularly.","Must",null,"Data Contributor \nIdentity Provider "]
[1.3,"Physical Security Standard v1.8","HICs must ensure that highly sensitive facilities that house identity provider services and data contribution endpoints are not accessible to the public. Details about highly sensitive facilities should be kept confidential (e.g., by using discrete signs or excluding details from directories or telephone books).","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"When signage is developed and deployed this should take into consideration the sensitivity of the systems.\n\nLocations should not be published or shared except for those with a need-to-know.","Scope includes assets under scope of assessment."]
[1.4,"Physical Security Standard v1.8","HICs should ensure that visitors to highly sensitive facilities are:\n- Permitted physical access only for specific, authorized purposes\n- Monitored by recording arrival and departure times\n- Obliged to wear visitor badges at all times\n- Supervised at all times, and\n- Made aware of behaviour or actions that are prohibited (e.g., filming or photography)","Should",null,"Data Contributor \nIdentity Provider "]
[1.5,"Physical Security Standard v1.8","HICs should ensure that data contribution endpoints and identity provider services are protected from power failures and other disruptions caused by failures in supporting utilities (e.g., electricity, water supply, heating/ventilation, and air-condition).","Should",null,"Data Contributor \nIdentity Provider "]
[1.6,"Physical Security Standard v1.8","HICs should ensure that power cables to highly sensitive facilities hosting the data contribution endpoints and identity provider services are protected. Methods of protection may include:\n- Segregating them from communications cables to prevent interference\n- Concealed installation\neHealth Ontario EHR Policy –Physical Security 4\n- Locked inspection/termination points\n- Alternative feeds or routing, and\n- Avoidance of routes through public areas.","Should",null,"Data Contributor \nIdentity Provider "]
[1.7,"Physical Security Standard v1.8"," HICs must ensure that the power supply for data contribution endpoints and identity provider services are protected and meet vendor requirements. Methods of protection may include:\n- Using uninterruptible power supply (UPS) devices that have enough battery capacity to support an orderly shutdown\n-  Installing surge protection equipment\n-  Providing back-up electricity generators in the event of an extended power supply\n- Installing emergency lighting in case of main power failure, and\n- Locating emergency power-off switches near emergency exits to facilitate rapid power-down in case of an emergency.\n- Meeting the vendor-specified requirements for cooling, heating, humidity and air quality.\n\n","Must","CISO","Data Contributor \nIdentity Provider ",null,null,null,null,null,"Organizations need to consider resiliency controls to ensure that the environment can remain operational and that the necessary safety protocols are in place.","Scope includes assets under scope of assessment."]
[1.8,"Physical Security Standard v1.8","Telecommunications cabling used to transmit information that supports data contribution endpoints and identity provider services must be protected from interception or damage. Methods of protection may include:\n- Installation of armoured conduit, and locked rooms or boxes at inspection and termination points\n- Use of alternative routings and/or transmission media\n- Use of fibre optic cabling\n- Use of electromagnetic shielding to protect the cables\n- Placement of redundant links\n- Initiation of technical sweeps and physical inspections for unauthorized devices being attached to the cables, and\n- Controlled access to patch panels and cable rooms.","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"The practices outlined in the policy requirements should be executed to ensure that information in transmission is protected.","Scope includes assets under scope of assessment."]
[1.9,"Physical Security Standard v1.8","HICs should ensure that highly sensitive facilities hosting data contribution endpoints and identity provider services are protected from natural and man-made hazards (e.g. in an area with a low risk of flooding, fire, explosion, or damage from neighbouring activities).","Should",null,"Data Contributor \nIdentity Provider "]
[1.1000000000000001,"Physical Security Standard v1.8","HICs should minimize the impact of hazards in highly sensitive facilities hosting data contribution endpoints and identity provider services by:\n- Locating fire extinguishers so that minor incidents can be tackled without delay\n- Training agents, and where appropriate Electronic Service Providers, in the use of fire extinguishers, other emergency/safety equipment, and in emergency evacuation procedures\n- Monitoring and controlling the temperature and humidity.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1100000000000001,"Physical Security Standard v1.8","HICs must ensure that fire alarms in highly sensitive facilities hosting data contribution endpoints and identity provider services are monitored continuously, tested regularly and serviced in accordance with manufacturer specifications and regulatory requirements","Must",null,"Data Contributor \nIdentity Provider "]
[1.1200000000000001,"Physical Security Standard v1.8","HICs should ensure that existing data centre facilities and those being acquired by lease, purchase, or construction hosting data contribution endpoints and identity provider services are periodically assessed to ensure that physical security controls are in place to physically protect the information stored or processed in that data centre.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1299999999999999,"Physical Security Standard v1.8","HICs should layer physical security zones in data centres hosting data contribution endpoints and identity provider services to provide for defence in depth protection.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1399999999999999,"Physical Security Standard v1.8","HICs must ensure that physical access points in data centres hosting data contribution endpoints and identity provider services, such as delivery and loading areas and other points where unauthorized persons may enter the premises are controlled","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Care needs to be taken during deliveries and shipments to ensure that adequate security is maintained.","Scope includes assets under scope of assessment."]
[1.1499999999999999,"Physical Security Standard v1.8","HICs should require their agents and Electronic Service Providers to obtain approval before leaving the data centre premises with technology used to operate identity provider services and data contribution endpoints.","Should","CISO","Data Contributor \nIdentity Provider "]
[2.1,"Physical Security Standard v1.8","[The EHR Solution] Program must implement physical security perimeters to protect physical components of [the EHR Solution] from unauthorized physical access and environmental damage.","Must",null,"Program Office"]
[2.2000000000000002,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that the strength of each perimeter depends on the physical security requirements of the information and information technology within the perimeter and, if applicable, the results of a threat risk assessment.","Must",null,"Program Office"]
[2.2999999999999998,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that highly sensitive facilities (i.e., buildings or storage areas that house information systems that store or process PHI or Restricted information) are protected against unauthorized physical access. Methods for preventing physical access may include:\n- Fitting vulnerable doors and windows with locks or bolts.\n- Installing and monitoring closed-circuit television (CCTV).\n- Employing security guards.\n- Installing intruder detection systems on external doors and testing accessible windows regularly.","Must",null,"Program Office"]
[2.4,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that highly sensitive facilities are located away from areas that are easily accessible to the public. Details about highly sensitive facilities should be kept confidential (e.g., by using discrete signs or excluding details from directories or telephone books).","Must",null,"Program Office"]
[2.5,"Physical Security Standard v1.8","[The EHR Solution] Program should ensure that visitors to highly sensitive facilitates are:\n- Permitted physical access only for specific, authorized purposes\n- Monitored by recording arrival and departure times\n- Obliged to wear visitor badges at all times\n- Supervised at all times, and\n- Made aware of behaviour or actions that are prohibited (e.g., filming or photography).","Should",null,"Program Office"]
[2.6,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that highly sensitive information systems (e.g., information systems that store or process PHI or Restricted information) are protected from power failures and other disruptions caused by failures in supporting utilities (e.g., electricity, water supply, heating/ventilation, and air-condition).","Must",null,"Program Office"]
[2.7,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that power cables to highly sensitive facilities are protected. Methods of protection may include:\n- Segregating them from communications cables to prevent interference\n- Concealed installation\n- Locked inspection/termination points\n- Alternative feeds or routing, and\n- Avoidance of routes through public areas.","Must",null,"Program Office"]
[2.8,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that the power supply to highly sensitive facilities is protected. Methods of protection may include:\n- Using uninterruptible power supply (UPS) devices that have enough battery capacity to support the orderly shutdown of sensitive information systems\n- Installing surge protection equipment\n- Providing back-up electricity generators in the event of an extended power supply\n- Installing emergency lighting in case of main power failure, and\n- Locating emergency power-off switches near emergency exits to facilitate rapid power-down in case of an emergency.\n- Meeting  the vendor-specified requirements for cooling, heating, humidity and air quality.","Must",null,"Program Office"]
[2.9,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that telecommunications cabling that transmits information that supports [the EHR Solution] are protected from interception or damage. Methods of protection may include:\n- Installation of armoured conduit and locked rooms or boxes at inspection and termination points\n- Use of alternative routings and/or transmission media\n- Use of fibre optic cabling\n- Use of electromagnetic shielding to protect the cables\n- Placement of redundant links\n- Initiation of technical sweeps and physical inspections for unauthorized devices being attached to the cables, and\n- Controlled access to patch panels and cable rooms.","Must",null,"Program Office"]
[2.1,"Physical Security Standard v1.8","[The EHR Solution] Program should ensure that telecommunications equipment is connected to the utility provider by at least two diverse routes to prevent connection failures.","Should",null,"Program Office"]
[2.11,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that highly sensitive facilities are protected from natural and man-made hazards (e.g. in an area with a low risk of flooding, fire, explosion, or damage from neighbouring activities).","Must",null,"Program Office"]
[2.12,"Physical Security Standard v1.8","[The EHR Solution] Program must minimize the impact of hazards in highly sensitive facilities by:\n- Locating fire extinguishers so that minor incidents can be tackled without delay\n- Training agents, and where appropriate Electronic Service Providers, in the use of fire extinguishers, other emergency/safety equipment, and in emergency evacuation procedures\n- Monitoring and controlling the temperature and humidity.","Must",null,"Program Office"]
[2.13,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that fire alarms in highly sensitive facilities are monitored continuously, tested regularly and serviced in accordance with manufacturer specifications.","Must",null,"Program Office"]
[2.14,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that existing data centre facilities, and those being acquired by lease, purchase, or construction, are periodically assessed to ensure that physical security controls are in place to physically protect the information stored or processed in that data centre.","Must",null,"Program Office"]
[2.15,"Physical Security Standard v1.8","[The EHR Solution] Program data centres facilities must be separated into distinct areas depending on operational requirements (e.g., server rooms, wiring closets, call centres, system support areas, service delivery, receiving, etc.).\n\nEach area must be assigned a physical security zone to determine the physical security controls. Physical security zones with the corresponding minimum physical security controls for [the EHR Solution] are found in Appendix A: [the EHR Solution] Physical Security Zones.","Must",null,"Program Office"]
[2.16,"Physical Security Standard v1.8","[The EHR Solution] Program must layer physical security zones in data centres to provide for defence in depth protection.\n\nIf such an approach is not feasible (e.g., due to the physical layout of a particular environment or specific operational requirements), then the maximum number of zones that may be skipped in the design of a data centre environment must be limited to one. In such cases, the relevant threat risk assessment must reflect the skipped zone, and compensating controls must be investigated and implemented.","Must",null,"Program Office"]
[2.17,"Physical Security Standard v1.8","[The EHR Solution] Program must ensure that physical access points in data centres, such as delivery and loading areas and other points where unauthorized persons may enter the premises must be controlled. ","Must",null,"Program Office"]
[2.1800000000000002,"Physical Security Standard v1.8","[The EHR Solution] Program must require all agents and Electronic Service Providers to obtain approval from a senior-level executive in [the EHR Solution] Program before leaving the data centre premises with information technology that is necessary for the operation of their information systems (e.g., servers and network devices). A record of all assets removed off-site should be maintained.","Must",null,"Program Office"]
[null,"System Development Life Cycle Standard v1.9",null,null,null,"null"]
[1.1000000000000001,"System Development Life Cycle Standard v1.9","HICs should implement controls to segregate their production environments from their non-production environments. These controls may include:\n- Using separate access controls\n- Using separate hardware for production and non-production activities, or\n- Segmenting the production network from non-production networks (e.g., through the use of network gateways).","Should",null,"Data Contributor \nIdentity Provider "]
[1.2,"System Development Life Cycle Standard v1.9","HICs must implement controls to segregate their production environments from their non-production environments. These controls may include:\n- Using separate access controls\n- Using separate hardware for production and non-production activities, or\n- Segmenting the production network from non-production networks (e.g., through the use of network gateways).","Must",null,"Data Contributor \nIdentity Provider "]
[1.3,"System Development Life Cycle Standard v1.9","HICs should perform an initial information security review on new or proposed upgrades or modifications to their identity provider services and data contribution endpoints.","Should",null,"Data Contributor \nIdentity Provider "]
[1.4,"System Development Life Cycle Standard v1.9","HICs should document information security requirements of their identity provider services and data contribution endpoints so that they can be used as a basis for requirements of future releases of these systems.","Should",null,"Data Contributor \nIdentity Provider "]
[1.5,"System Development Life Cycle Standard v1.9","HICs should review design specifications and processes for new or proposed modifications to their identity provider services and data contribution endpoints to ensure that sufficient controls are place to address information security requirements.","Should",null,"Data Contributor \nIdentity Provider "]
[1.6,"System Development Life Cycle Standard v1.9","HICs should protect any source code related to their identity provider services and data contribution endpoints against unauthorized access and modification (e.g., through the use of access controls).","Should",null,"Data Contributor \nIdentity Provider "]
[1.7,"System Development Life Cycle Standard v1.9","HICs should store all source code related to their identity provider services and data contribution endpoints in a source code repository and implement version control to manage code development.","Should",null,"Data Contributor \nIdentity Provider "]
[1.8,"System Development Life Cycle Standard v1.9","HICs should require custom code related to their identity provider services and data contribution endpoints to be reviewed prior to release into production. Reviews of custom code (“code reviews”) may be performed manually or with the assistance of automated review tools.","Should",null,"Data Contributor \nIdentity Provider "]
[1.9,"System Development Life Cycle Standard v1.9","HICs should ensure that security deficiencies or vulnerabilities identified during the code review are corrected or the risk is accepted prior to production implementation.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1000000000000001,"System Development Life Cycle Standard v1.9","HICs must ensure that procedures for testing identity provider services and data contribution endpoint developments cover the:\n- Types of hardware, software and services to be tested\n- Use of structured test plans, including user involvement\n- Types of testing (e.g., end-to-end and performance testing)\n- Data use for performing tests, and\n- Document, review and sign-off of the testing results.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1100000000000001,"System Development Life Cycle Standard v1.9","HICs should conduct tests on new identity provider services and data contribution endpoints with the system running in expected, unexpected (e.g. excessive load, or unavailable services), and infrequent (e.g. limited connectivity or delayed service responses) conditions.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1200000000000001,"System Development Life Cycle Standard v1.9","HICs must perform vulnerability assessments on their identity provider services and data contribution endpoints to identify weaknesses in the information security controls and perform penetration tests to demonstrate how vulnerabilities can be exploited.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1299999999999999,"System Development Life Cycle Standard v1.9","HICs should implement a process to ensure that flaws or security weaknesses identified during the testing process for their identity provider services and data contribution endpoints are resolved in a consistent manner.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1399999999999999,"System Development Life Cycle Standard v1.9","Before new identity provider services or data contribution endpoints are promoted into the production environment, HICs must ensure that:\n- Information security assessments have been performed.\n- Limitations of information security controls have been documented.\n- Service level agreements have been established to support systems in the production environment, if required.","Must",null,"Data Contributor \nIdentity Provider "]
[1.1499999999999999,"System Development Life Cycle Standard v1.9","HICs should define and implement an installation process or deployment plan.","Should",null,"Data Contributor \nIdentity Provider "]
[1.1599999999999999,"System Development Life Cycle Standard v1.9","HICs should create a rollback strategy prior to implementing changes.","Should",null,"Data Contributor \nIdentity Provider "]
[1.17,"System Development Life Cycle Standard v1.9","HICs should only permit specific agents and Electronic Service Providers to update production operational software, applications, and program libraries.","Should",null,"Data Contributor \nIdentity Provider "]
[1.18,"System Development Life Cycle Standard v1.9","HICs must document and implement a change control process to govern all changes to production identity provider services and data contribution endpoints.","Must",null,"Data Contributor \nIdentity Provider "]
[1.19,"System Development Life Cycle Standard v1.9","HICs should ensure that their change control process:\n- Maintains a record of agreed authorization levels.\n- Ensures changes are submitted by authorized users.\n- Reviews information security controls to ensure that they will not be compromised by the changes.\n- Identifies all software, information, database entries, and hardware that require amendment.\n- Obtains formal approval from information system owner for detailed proposals before work commences.\n- Ensures authorized users accept changes prior to implementation.\n- Ensures the information system documentation set (i.e., the document(s) relevant to the information system being changed) is updated on the completion of each change, and the old documentation is archived or disposed.\n- Maintains a version control for all software updates.\n- Maintains an audit trail of all change requests.\n- Ensures that all information included in the change control process (database names, accounts, network addresses, etc.) are disclosed only to the relevant parties in the appropriate steps of the change control procedure.","Should",null,"Data Contributor \nIdentity Provider "]
[1.2,"System Development Life Cycle Standard v1.9","HICs should develop a process to test the information security controls of their information systems after implementation. The process should ensure that:\n- A review of the application control and integrity procedures is completed to ensure that they have not been compromised by the operating system changes.\n- Appropriate changes are made to the business continuity plans.","Should",null,"Data Contributor \nIdentity Provider "]
[2.1,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must perform development and testing activities in non-production environments.","Should",null,"Program Office"]
[2.2000000000000002,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must implement controls to segregate their production environments from their non-production environments keeping in mind the sensitivity of the data in non-production environments and practices. These controls should include:\n- Using separate access controls\n- Using separate hardware for production and non-production activities, or\n- Segmenting the production network from non-production networks (e.g., through the use of network gateways).\n- Creating separate warning banners and display features that clearly indicate the environment.","Must",null,"Program Office"]
[2.2999999999999998,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should perform an initial information security review on all their proposed information systems based on the known information system requirements and the business objectives to provide information security requirements for the developers.","Should",null,"Program Office"]
[2.4,"System Development Life Cycle Standard v1.9","Where the information security functionality in a proposed product does not satisfy the specified information security requirements, then [the EHR Solution] Program should consider the risks that would be introduced by the information system prior to purchasing the product.","Should",null,"Program Office"]
[2.5,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should document information security requirements so that they can be used as a basis for requirements of future releases of the information system.","Should",null,"Program Office"]
[2.6,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should review their information system development design specifications and processes to ensure that sufficient controls are place to address information security requirements.","Should",null,"Program Office"]
[2.7,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should use the information requirements for the application to document the information system architecture design.","Should",null,"Program Office"]
[2.8,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should develop and document a detailed design for each information system module, component, or service. The detailed design should be refined into lower levels containing application units that can be coded, compiled, and tested.","Should",null,"Program Office"]
[{"$f":"A658+0.1","v":2.9},"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should develop and document a detailed design for the interfaces external to the information system module/component/service, between the information system components, and between the application units.","Should",null,"Program Office"]
[2.1,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must protect source code against unauthorized access and modification (e.g., through the use of access controls).","Must",null,"Program Office"]
[2.11,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should store all source code in a source code repository and implement version control to manage code development.","Should",null,"Program Office"]
[2.12,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should develop all applications in accordance with secure coding guidelines. Guidance on secure coding is available from:\n- CERT®\n- National Institute of Standards and Technology (NIST)\n- Open Web Application Security Project (OWASP), or\n- SANS Institute","Should",null,"Program Office"]
[2.13,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must ensure that accounts, user IDs, private encryption keys, and passwords are not imbedded in the source code or published solution.","Must",null,"Program Office"]
[2.14,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should review all custom code prior to release into production. Reviews of custom code (“code reviews”) should be performed manually or with the assistance of automated review tools.","Should",null,"Program Office"]
[2.15,"System Development Life Cycle Standard v1.9","All manual code reviews should be performed by agents or Electronic Service Providers other than the original custom code developer (or outsourced code developer), and who are knowledgeable in code review techniques and secure coding practices.","Should",null,"Program Office"]
[2.16,"System Development Life Cycle Standard v1.9","All code reviews should identify and remediate, at a minimum, all of the following coding vulnerabilities:\n- Injection flaws: The code reviewer must validate input to verify that data inputted by an end user cannot modify the meaning of commands and queries, utilize parameterized queries, etc. (e.g., to prevent SQL injection, OS Command Injection, LDAP and XPath injection flaws).\n- Buffer overflows: The code reviewer must validate buffer boundaries and truncate input strings.\n- Insecure cryptographic storage: The code reviewer must validate that cryptographic functions are used properly when used to protect stored data\n- Insecure communication: The code reviewer must validate that all authenticated and sensitive communications are properly encrypted.\n- Improper error handling: The code reviewer must validate that sensitive information is not leaked via error messages.","Should",null,"Program Office"]
[2.17,"System Development Life Cycle Standard v1.9","In addition to the above, all custom code used for web applications and application interfaces must be tested and remediated for all of the following coding vulnerabilities:\n- Cross-site scripting (XSS): The code reviewer must validate all parameters before inclusion, utilize context sensitive escaping, etc.\n- Improper Access Control: The code reviewer must validate that end users are properly authenticated, input is sanitized, and internal object references are not exposed to end users and the access control is not bypassed via any backdoors.\n- Cross-site request forgery (CSRF): The code reviewer must validate that applications do not reply on authorization credentials and tokens automatically submitted by browsers.\n- Invalidated Redirects and Forwards: The code reviewer must validate that all the supplied URL values are valid and authorized for the user.","Must",null,"Program Office"]
[2.1800000000000002,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must ensure that all security deficiencies or vulnerabilities identified during the code review are corrected or the risk is accepted prior to production implementation.","Must",null,"Program Office"]
[2.19,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should ensure that code review results are reviewed, approved, and signed-off by their respective management prior to release.","Should",null,"Program Office"]
[2.2000000000000002,"System Development Life Cycle Standard v1.9","Where access to external party source code (or equivalent) is restricted, [the EHR Solution] Program should ensure that a copy of the code is:\n- Maintained in escrow by a trusted external party, and\n- Checked regularly to ensure it is up-to-date and works correctly.","Should",null,"Program Office"]
[2.21,"System Development Life Cycle Standard v1.9","Vendor-supplied software packages should be used without modification (i.e. without modification to the base vendor application features).","Should",null,"Program Office"]
[2.2200000000000002,"System Development Life Cycle Standard v1.9","When a vendor-supplied package needs to be modified, [the EHR Solution] Program should consider the following:\n- The risk of built-in controls and integrity processes being compromised.\n- Obtaining the required changes from the vendor as a standard program update.\n- The impact of becoming responsible for future maintenance of the software as a result of the change.","Should",null,"Program Office"]
[2.23,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must ensure that procedures for testing information systems under development cover the:\n- Types of hardware, software and services to be tested\n- Use of structured test plans, including user involvement\n- Types of testing (e.g., end-to-end and performance testing)\n- Data use for performing tests, and\n- Document, review and sign-off of the testing results.","Must",null,"Program Office"]
[2.2400000000000002,"System Development Life Cycle Standard v1.9","New information systems should be tested in accordance with predefined, documented test plans, which shall be cross-referenced to the information system design/specification to ensure complete coverage. Key user representatives should be involved in planning tests, providing test data and reviewing test results.","Should",null,"Program Office"]
[2.25,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should ensure that the information system testing environment mimics the production environment to the greatest degree possible.","Should",null,"Program Office"]
[2.2599999999999998,"System Development Life Cycle Standard v1.9","The complete information system environment should be tested to identify any conflicts or dependencies with other information systems, which includes:\n- Using the underlying technical security infrastructure.\n- Interfacing with other applications.\n- Running different operating systems, runtime libraries and browser software.\n- Interfacing with databases and directory services, and\n- Processing on particular hardware, including service/mobile device/hand-held configurations","Should",null,"Program Office"]
[2.27,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should conduct information system tests with the information system running in expected, unexpected (e.g. excessive load, or unavailable services), and infrequent (e.g. limited connectivity or delayed service responses) conditions.","Should",null,"Program Office"]
[2.2799999999999998,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should not use production data, with the exception of data classified as Public, in non-production environments, unless the information security controls in the non-production environment mirrors the information security controls implemented (or to be implemented) in the production environment. Otherwise, [the EHR Solution] Program should sanitize all production data (e.g., masked, scrambled, scrubbed), prior to loading and using it in non-production environments, in a way that:\n- A record or transaction cannot be traced to an individual.\n- The information, if disclosed to unauthorized individuals, will not have an adverse effect on [the EHR Solution], its agents or Electronic Service Providers, or HICs, their agents or Electronic Service Providers, or any patient.","Should",null,"Program Office"]
[2.29,"System Development Life Cycle Standard v1.9","Security testing activities should be incorporated where possible as part of the overall testing activities of [the EHR Solution] to provide frequent feedback on potential information security enhancements or improvements.","Should",null,"Program Office"]
[2.2999999999999998,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must perform vulnerability and configuration scans on any new infrastructure deployment or service prior to its production release, with all [EHR Solution] major releases being supported by a comprehensive vulnerability assessment.","Must",null,"Program Office"]
[2.31,"System Development Life Cycle Standard v1.9","[The EHR Solution] program must perform penetration tests on all major releases of internet-facing applications that are part of [the EHR Solution] and that provide or support access to PHI prior to its availability in the production environment.","Must",null,"Program Office"]
[2.3199999999999998,"System Development Life Cycle Standard v1.9","Penetration tests on internet-facing applications must include web-application testing techniques executed against a documented set of industry standards such as the OWASP Top 10 to identify weakness that are unique to web-based applications (e.g., SQL/LDAP injection, cross-site scripting, session token attacks and URL forgery) and must be subject to rigorous external content review.","Must",null,"Program Office"]
[2.33,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should use prepared test data (e.g., high volume of concurrent users, URLs, command-line inputs and random data) designed to identify system faults or system weaknesses (e.g., buffer overflow and faulty memory) to perform information security tests on their information systems.","Should",null,"Program Office"]
[2.34,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should implement a process to ensure that flaws or security weaknesses identified during the testing process are resolved in a consistent manner, which includes:\n- Recording details of security weaknesses identified (e.g., in a test log.)\n- Assessing the associated risks\n- Implementing actions to address these risks\n- Repeating tests of the application following corrective actions, and\n- Security testing results that identify weaknesses should be handled as confidential until the specific flaw has been addressed.","Should",null,"Program Office"]
[2.35,"System Development Life Cycle Standard v1.9","Where information security testing reveals one or more weaknesses in a third-party product, [the EHR Solution] Program should communicate their findings directly to the third-party.","Should",null,"Program Office"]
[2.36,"System Development Life Cycle Standard v1.9","Before new information systems are promoted into the production environment, [the EHR Solution] Program must ensure that:\n- Information security assessments have been performed\n- Limitations of information security controls have been documented\n- Approval has been obtained from an appropriate representative, and\n- Service level agreements have been established to support systems in the production environment, if required.","Must",null,"Program Office"]
[2.37,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should not permit code to be promoted directly from a development environment to a production environment, or vice versa, but should require all code to follow a code promotion process.","Should",null,"Program Office"]
[2.38,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must only permit executable code to be promoted to the production environment. Development code or compliers must be prohibited in the production environment.","Must",null,"Program Office"]
[2.39,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should define and implement an installation process or deployment plan.","Should",null,"Program Office"]
[2.4,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should create a rollback strategy prior to implementing changes.","Should",null,"Program Office"]
[2.41,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should use a configuration control system to keep control of all implemented software, as well as the system documentation.","Should",null,"Program Office"]
[2.42,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should only permit designated agents and Electronic Service Providers to update production operational software, applications, and program libraries.","Should",null,"Program Office"]
[2.4300000000000002,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must implement a change control process to govern all changes to production information systems.","Must",null,"Program Office"]
[2.44,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program should ensure that their change control process:\n- Maintains a record of agreed authorization levels\n- Ensures changes are submitted by authorized users\n- Reviews information security controls to ensure that they will not be compromised by the changes\n- Identifies all software, information, database entries, and hardware that require amendment\n- Obtains formal approval from information system owner for detailed proposals before work commences\n- Ensures authorized users accept changes prior to implementation\n- Ensures the information system documentation set (i.e., the document(s) relevant to the information system being changed) is updated on the completion of each change, and the old documentation is archived or disposed\n- Maintains a version control for all software updates\n- Maintains an audit trail of all change requests, and\n- Ensures that all information included in the change control process (database names, accounts, network addresses, etc.) are disclosed only to the relevant parties in the appropriate steps of the change control procedure.","Should",null,"Program Office"]
[2.44,"System Development Life Cycle Standard v1.9","[The EHR Solution] Program must develop a process to test the information security controls of their information systems after implementation. The process should ensure that:\n- A review of the application control and integrity procedures is completed to ensure that they have not been compromised by the operating system changes, and\n- Appropriate changes are made to the business continuity plans.","Must",null,"Program Office"]
[null,"Threat Risk Management Standard v1.8",null,null,null,"null"]
[1.1000000000000001,"Threat Risk Management Standard v1.8","HICs are responsible for performing Threat Risk Assessments (TRAs) on their own identity provider services and data contribution endpoints. HICs may have a TRA performed by an entity on their behalf and leverage that work to satisfy this requirement. These may include threat risk assessment methodologies published or recommended by:\n-  Communications Security Establishment Canada (CSEC)\n-  National Institute of Standards and Technology (NIST)\n-  International Organization for Standardization (ISO)\n-  European Network for Information Security Agency (ENISA)\n","Must",null,"Data Contributor \nIdentity Provider ",null,null,null,null,null,"Under the policy, HSPs are not required to conduct a TRA. The security policy assessment evaluates gaps in safeguards which are then translated into Risks.\n\nOrganization can acknowledge this control or develop plan to enhance capabilities or conduct their own assessment","Scope includes assets under scope of assessment."]
[1.2,"Threat Risk Management Standard v1.8","HICs should request executive summaries (results) of TRAs that are completed on [the EHR Solution].","Should",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Organizations participating in the EHR Solution have the option to request the TRA executive summary from the Program Office.  Email security@ehealthontario.on.ca to request the results of the TRA.","Scope includes TRAs that are done on the EHR Solution by the Program Office"]
[1.3,"Threat Risk Management Standard v1.8","Where a HIC receives a TRA from [the EHR Solution] Program, the HIC must restrict access to that TRA and any supporting documentation, and ensure that the TRA is handled in a secure manner.","Must",null,"Data Contributor \nIdentity Provider \nViewer",null,null,null,null,null,"Where organizations receive the TRA they must keep it secure and only make it available to those authorized.  E.g. Store it with the safeguards in place (encryption applied), any physical printed copies must remain locked up when not in use. ","Scope includes EHR Solution TRAs that are done by the Program Office which are shared with your organization."]
[1.4,"Threat Risk Management Standard v1.8","HICs must perform a TRA or delta TRA or EHR security assessment under the following conditions:\n- Prior to changing to EHR consumption roles, based on corresponding recommendations from eHealth Ontario\n-Prior to significant modification to existing back-end architecture or functionality\n-HIC must perform an information security threat risk assessment (TRA) if this is a mandatory requirement as part of the project governance/SDLC process\n- Prior to a significant changes to existing front-end technical design or functionality\n- Prior to significant changes to operational support models, tools, process, or parties\n- Prior to significant changes to existing policies or procedures\n- Prior to providing new Electronic Service Providers with access to [the EHR Solution]\n- Prior to changes to applicable agreements that could be expected to impact the privacy of individuals or the security of their PHI.\n- Prior to Legislative changes to PHIPA that could be expected to impact the privacy of individuals or the security of their PHI\n- On discovery of a vulnerability that resulted in, or could have resulted in, an information security incident that affects or would have affected [the EHR Solution], or\neHealth Ontario EHR Policy – Threat Risk Management Policy 4\n- Every five years if none of the above has initiated a comprehensive TRA.","Must",null,"Data Contributor \nIdentity Provider "]
[1.5,"Threat Risk Management Standard v1.8","HICs should document and monitor all their risks in a risk register with identified owners, action plans (risk treatment option details), and status. Risks should be reviewed quarterly and risk treatment options updated if required.","Should","IT","Data Contributor \nIdentity Provider "]
[2.1,"Threat Risk Management Standard v1.8","[The EHR Solution] Program shall be responsible for performing TRAs on [the EHR Solution].","Must",null,"Program Office"]
[2.2000000000000002,"Threat Risk Management Standard v1.8","[The EHR Solution] Program must perform all threat risk assessments (TRAs) in accordance with the Harmonized Threat and Risk Assessment Methodology published by the Communications Security Establishment Canada (CSEC).","Must",null,"Program Office"]
[2.2999999999999998,"Threat Risk Management Standard v1.8","[The EHR Solution] Program shall make executive summaries (results) of TRAs and relevant risk treatment plans available on request to HICs who have access to [the EHR Solution] within three business days upon approval of the TRA and remediation plan by the Applicable Oversight Body.","Must",null,"Program Office"]
[2.4,"Threat Risk Management Standard v1.8","[The EHR Solution] Program shall maintain:\n- An asset listing that contains valuation and classification ratings for [the EHR Solution], and\n- A risk listing that contains threat and vulnerability ratings for [the EHR Solution].","Must",null,"Program Office"]
[2.5,"Threat Risk Management Standard v1.8","All revisions to asset and risk listings must be approved by the Applicable Oversight Body.","Must",null,"Program Office"]
[2.6,"Threat Risk Management Standard v1.8","[The EHR Solution] Program must treat all completed or partially completed TRAs and supporting documentation in accordance with the protection requirements for information classified as Confidential.","Must",null,"Program Office"]
[2.7,"Threat Risk Management Standard v1.8","[The EHR Solution] Program must perform a TRA or delta TRA on [the EHR Solution] under the following conditions:\n- Prior to significant modification to existing back-end architecture or functionality\n- Prior to significant changes to existing front-end technical design or functionality\n- Prior to significant changes to operational support models, tools, process, or parties\n- Prior to significant changes to existing policies or procedures\n- Prior to a change of Electronic Service Provider\n- Prior to changes to applicable agreements that could be expected to impact the privacy of individuals or the security of their PHI\n- Prior to Legislative changes to PHIPA that could be expected to impact the privacy of individuals or the security of their PHI\n- On discovery of a vulnerability that resulted in, or could have resulted in, an information security incident as deemed necessary by Connecting Security Committee, or\n- At a minimum, every two years if none of the above has initiated a comprehensive TRA.","Must",null,"Program Office"]
[2.8,"Threat Risk Management Standard v1.8","[The EHR Solution] Program must document a risk treatment option for all risks identified through the TRA process. Risk treatment options may include one or more of the following:\n- Applying additional information security controls to further reduce the risk\n- Accepting the risk, or\n- Avoiding the risk by not allowing actions that would cause the risk to occur.","Must",null,"Program Office"]
[2.9,"Threat Risk Management Standard v1.8","Where [the EHR Solution] Program chooses as the risk treatment option to apply additional information security controls, these controls must be implemented to meet the requirements identified in the TRA.","Must",null,"Program Office"]
[2.1,"Threat Risk Management Standard v1.8","[The EHR Solution] Program must document and monitor all their accepted risks in a risk register with identified owners, action plans (risk treatment option details), and status. Risks should be reviewed quarterly and risk treatment options updated if required.","Must",null,"Program Office"]
[2.11,"Threat Risk Management Standard v1.8","[The EHR Solution] Program must present all their TRAs to eHealth Ontario who will facilitate reporting to the Connecting Security Committee and, to the Applicable Oversight Body for sign off.\nWhere medium or higher residual risks exist, the TRA must also be signed off by a senior level executive (e.g., CIO) in [the EHR Solution] Program prior to submission to  eHealth Ontario.","Must",null,"Program Office"]
[]
[]
["Legend "]
["Count","Status Code","Meaning",null,null,null,"Contribution %"]
[{"$f":"COUNTIF($G$11:$G$712, \"I\")","v":0},"I","Control is Implemented or similar / equivalent control exists",null,null,null,{"$f":"A717/$A$720","v":{"$error":"#DIV/0!"}}]
[{"$f":"COUNTIF($G$11:$G$712, \"NI\")","v":0},"NI","Control is Not Implemented - remediation is required.",null,null,null,{"$f":"A718/$A$720","v":{"$error":"#DIV/0!"}}]
[{"$f":"COUNTIF($G$11:$G$712, \"NA\")","v":0},"NA (Not Applicable)","Control is Not Applicable for the organization.",null,null,null,{"$f":"A719/$A$720","v":{"$error":"#DIV/0!"}}]
[{"$f":"SUM(A717:A719)","v":0}]
[]
[]
["# of controls to implement within 3 months",{"$f":"COUNTIF($G$11:$H$712, \"Within 3 months\")","v":0}]
["# of controls to implement within 6 months",{"$f":"COUNTIF($G$11:$H$712, \"Within 6 months\")","v":0}]
["# of controls to implement within 9 months",{"$f":"COUNTIF($G$11:$H$712, \"Within 9 months\")","v":0}]
["# of controls to implement within 1 year",{"$f":"COUNTIF($G$11:$H$712, \"Within 1 year\")","v":0}]

{"sheet":"Dashboard","index":3,"n_rows":0,"n_cols":0,"rows_kept":0,"cut":false,"hidden":false,"merged":[]}

{"sheet":"Control Breakdown","index":4,"n_rows":37,"n_cols":10,"rows_kept":37,"cut":false,"hidden":true,"merged":[[23,5,23,6],[24,5,24,6],[25,5,25,6],[29,0,29,4],[29,5,29,6],[26,5,26,6],[27,5,27,6],[28,5,28,6],[1,0,1,2],[1,4,1,6],[20,5,20,6],[21,5,21,6],[22,5,22,6],[35,5,35,6],[36,5,36,6],[30,5,30,6],[31,5,31,6],[32,5,32,6],[33,5,33,6],[34,5,34,6]]}
["[The EHR Solution]  Security Readiness Assessment"]
["Role",null,null,null,"Control Count"]
["IDP","DC","Viewer","Program Office","Must","Should","Total"]
["Yes","Yes","Yes","No",230,85,{"$f":"E4+F4","v":315}]
["Yes","Yes","No","No",229,85,{"$f":"E5+F5","v":314}]
["Yes","No","No","No",229,85,314]
["Yes","No","Yes","No",230,85,315]
["No","Yes","Yes","No",172,85,257]
["No","No","Yes","No",68,9,77]
["No","Yes","No","No",171,85,256]
["No","No","No","No",0,0,0]
["No","No","No","Yes",312,67,379]
["Yes","Yes","Yes","Yes",534,152,686]
["Yes","Yes","No","Yes",533,152,685]
["Yes","No","No","Yes",370,67,437]
["Yes","No","Yes","Yes",534,152,686]
["No","Yes","Yes","Yes",476,152,628]
["No","No","Yes","Yes",476,152,628]
["No","Yes","No","Yes",475,152,627]
[]
["Policy",null,null,null,null,"Control # IDP",null,"Control # Viewer","Control # DC","Control # PO"]
["Acceptable Use of Information and Information Technology Policy",null,null,null,null,32,null,32,32,36]
["Access Control and Identity Management for System Level Access",null,null,null,null,38,null,0,38,49]
["Business Continuity",null,null,null,null,12,null,0,12,13]
["Cryptography Policy",null,null,null,null,32,null,2,32,49]
["Electronic Service Provider",null,null,null,null,5,null,5,5,8]
["Information Asset Management",null,null,null,null,1,1,1,1,8]
["Information Security Policy",null,null,null,null,11,13,3,11,19]
["Information Security Incident Management",null,null,null,null,22,22,22,22,25]
["Federation Identity Provider Standard",null,null,null,null,58,null,0,0,0]
["Security Logging and Monitoring",null,null,null,null,24,null,0,24,29]
["Local Registration Authority Practices",null,null,null,null,6,null,6,6,6]
["Network and Operations",null,null,null,null,33,37,4,33,63]
["Physical Security",null,null,null,null,15,null,0,15,18]
["System Development Life Cycle",null,null,null,null,20,21,0,20,45]
["Threat Risk Management",null,null,null,null,5,8,2,5,11]
["Total",null,null,null,null,{"$f":"SUM(F22:F36)","v":314},null,{"$f":"SUM(H22:H36)","v":77},{"$f":"SUM(I22:I36)","v":256},379]

{"sheet":"Summary","index":5,"n_rows":4,"n_cols":5,"rows_kept":4,"cut":false,"hidden":true,"merged":[[1,1,1,4]]}
[]
[null,"Implementation status by ISO 27001:2005 - Annexure - A Controls"]
[null,"Reference","Controls  implemented","Controls NOT Implemented","Controls not applicable"]
[null,"Controls",{"$f":"'Control Analysis'!$A$717","v":0},{"$f":"'Control Analysis'!$A$718","v":0},{"$f":"'Control Analysis'!$A$719","v":0}]

{"sheet":"Data","index":6,"n_rows":9,"n_cols":1,"rows_kept":9,"cut":false,"hidden":true,"merged":[]}
["Yes"]
["No"]
["Not Sure"]
[]
["Within 3 Months"]
["Within 6 Months"]
["Within 9 Months"]
["Within 1 Year"]
["NA"]