Language selection

OPC Logo Office of the Privacy Commissioner of Canada

Search

Investigation into CoreFour Inc.’s compliance with PIPEDA

PIPEDA Findings #2021-002

March 29, 2021

Overview

The complainant made several allegations about the privacy practices of CoreFour Incorporated (“CoreFour” or the “respondent”) concerning Edsby, the respondent’s Kindergarten to Grade 12 (“K-12”) learning management and analytics system, adopted by his children’s district school board (“school board”). In response to this complaint, our Office investigated CoreFour’s compliance with its safeguards, breach response and accountability obligations under PIPEDA.

With respect to safeguards, CoreFour collects, uses and discloses the personal information of hundreds of thousands of children from across Canada and other countries. Much of this information is potentially sensitive (including grades, absence details and health information). This would indicate a requirement for heightened security safeguards commensurate with the volume and sensitivity of the information.

We found that the respondent had implemented many effective security practices. However, we also confirmed the existence of two specific security vulnerabilities identified by the complainant: (i) weak password requirements for certain Edsby parental accounts; and (ii) inadequate safeguards to protect against unauthorized access to thumbnail images of student profile pictures. While the respondent addressed these vulnerabilities last year, we noted an additional vulnerability concerning Edsby’s failure to scan for malware when uploading content from third-party applications. CoreFour has also addressed this concern.

Ultimately, we established that the respondent lacked a robust overarching information security framework. In our view, had the respondent completed and implemented such a framework, it could have mitigated, and potentially avoided, the vulnerabilities identified. In this respect, CoreFour’s safeguards were not adequate.

The complainant further claimed that the respondent did not have an adequate mechanism for handling and reporting privacy breaches, and that it failed to notify parents, and our Office, of the vulnerabilities he had identified. We found that the respondent was in compliance with its breach-related obligations:

  1. In the case of the password management vulnerability, no actual breach had occurred, and in any event, private sector breach reporting was not yet mandatory when the respondent learned of this vulnerability.
  2. When the complainant notified the respondent of the student image vulnerability, mandatory breach reporting and notification had come into effect under PIPEDA. Our investigation identified, however, that the only breach associated with this vulnerability flowed from the complainant’s own actions, which did not result in a real risk of significant harm. In our view, therefore, the respondent was not required to report the breach to our Office, or notify affected parents. We note that, in any event, the respondent worked with the school board to support the latter’s notification of parents of affected students.
  3. The respondent had appropriate breach reporting procedures, and maintained a breach register, as required under PIPEDA.

Turning to accountability, we found that the respondent lacked a privacy management framework. It did not have appropriate written, internal policies and practices to give effect to PIPEDA principles, such as in relation to complaint handling and data retention and destruction, although certain of these documents were in development during our investigation. Nor did the respondent provide adequate privacy training to its employees, consultants, contractors and students. Finally, we found that the respondent’s Privacy Policy on its website was unclear in certain respects and could be improved. We therefore found that CoreFour failed to meet its accountability requirements under Principle 4.1.4 of the Act.

Taking into account the above, we recommended that the respondent implement certain safeguard enhancements, specifically: (i) completing and implementing an information security management framework; (ii) ensuring it has sufficient back-up IT security human resources, and maps out an appropriate segregation of security responsibilities; (iii) scanning for malware when importing content into Edsby from other software applications; and (iv) training its staff on the above policies, procedures and measures.

We also recommended that the respondent build a privacy management framework consistent with its accountability obligations under PIPEDA, including: (i) the development of complaint-handling, and data retention and destruction procedures; and (ii) the development and adoption of a privacy-training program. Finally, we recommended that CoreFour improve the clarity of certain aspects of its Privacy Policy.

We further requested that CoreFour provide our Office with a report from a qualified independent third party documenting and confirming the measures it has taken to implement the above recommendations.

CoreFour was co-operative with our Office throughout the investigation. In response to our recommendations, the company confirmed that it had introduced malware scanning functionality within Edsby in 2020. It was also in the process of seeking ISO 27001 certificationFootnote 1 which it believed would address our remaining concerns. CoreFour therefore committed to implement our recommendations within agreed timelines, including to provide the third-party report requested by our Office.

We therefore consider the safeguard and accountability matters to be well-founded and conditionally resolved, and the breach reporting and notification matter to be not well-founded.

We note that the complainant made additional allegations concerning the organization’s non-compliance with its consent and openness obligations under PIPEDA. We deemed these matters out of scope of our investigation. In determining the scope of our investigation, we considered that the complainant had also filed a separate complaint with the Office of the Information and Privacy Commissioner of Ontario (“IPC”), alleging that the school board failed to comply with its consent and openness obligations under Ontario’s Municipal Freedom of Information and Protection of Privacy Act (“MFIPPA”)Footnote 2, and the IPC was investigating those matters. We shared information with the IPC throughout our investigation, to help inform their investigation into these additional issues. Unfortunately, the IPC was unable to share information with our Office due to limitations in MFIPPA.

Background

The complaint

  1. The complainant made several allegations about the privacy practices of CoreFour Incorporated (“CoreFour” or the “respondent”) regarding its software application called Edsby: a Kindergarten to Grade 12 (“K-12”) learning management and analytics system (see paragraph 19 for further details). Specifically, the complainant alleged:

    Safeguards
    1. Information security vulnerabilities within Edsby discovered by the complainant, potentially exposed the personal information of students attending schools within an Ontario based school board, and that of their parents, to unauthorized access. Specifically:
      1. Edsby-managed parental accounts were inadequately protected due to the respondent’s poor password management practices (the “password vulnerability”); and
      2. images of student profile pictures were inadequately protected due to the respondent’s use of sequential file numbers in Edsby (the “profile image vulnerability”).
    2. Furthermore, the respondent did not have an adequate information security framework, resources, policies and standards in place to protect the sensitive personal information held on Edsby.
    Breach reporting and notification
    1. The complainant claimed that respondent did not have an adequate mechanism for handling and reporting privacy breaches and failed to notify parents, and our Office, of the above vulnerabilities.
    Accountability
    1. The complainant alleged that the respondent did not have adequate privacy policies and procedures in place to comply with its accountability obligations under PIPEDA.
    2. The respondent’s "Privacy Policy for Edsby" (the “privacy policy”) mischaracterized personal information, indicated that the respondent did not accept responsibility for the security of the personal information in its custody, and was unclear about the respondent’s sharing of user information with third parties.
    Consent
    1. The respondent failed to obtain direct consent from parents and guardians to collect, use, disclose and store their children’s personal information on the application.
    2. When he requested, via the school board, that the respondent remove his children’s information from Edsby, the complainant claims that the respondent initially failed to do so. The information was removed temporarily, until the school board informed him that his children’s information would no longer be excluded from Edsby, contrary to his wishes.
    Openness
    1. The respondent sent a notice to parents on behalf of the school board: (i) confirming that their children’s student records were now linked to Edsby; and (ii) inviting them to set up Edsby parental accounts. The complainant was concerned about the notice’s content, which he perceived to be confusing. He was concerned that the notice included links to pages with further information without appropriate explanation, and lacked transparency regarding what was being agreed to and how student and parent personal information would be handled.
  2. In his complaint and subsequent communications with our Office, the complainant explained that he had engaged the respondent, through the offices of the school board, in November 2017 and January 2019. He informed the school board and the respondent about security vulnerabilities he had found in Edsby as a result of his own research. He claimed that the respondent’s response, their reliance on following security “best practices” and their apparent lack of compliance with a security industry standard, suggested inadequate information security and privacy policies, procedures, standards and resources dedicated to protecting the information collected, used and stored in Edsby.
  3. The complainant also claimed that Edsby appeared to be a data aggregating and tracking tool with direct access to the school board’s SIS and other data sources, rather than a social learning application. He was particularly worried, based upon his review of the respondent’s Privacy Policy, about the potential for the respondent to share and sell student information to third parties.
  4. The complainant sought the temporary suspension of Edsby by the school board, until the information security and privacy issues (and other concerns) he had raised had been appropriately addressed by the respondent.
  5. Unsatisfied with the explanations provided to him, he filed the subject complaint with our Office.

Scope of our investigation

  1. In June 2018, the complainant filed a separate privacy complaint against the school board with the Office of the Information and Privacy Commissioner of Ontario (“IPC”). The complainant alleged that the school board failed to comply with its consent and openness obligations under Ontario’s MFIPPA legislation, when it adopted Edsby. The complainant also raised additional safeguard and accountability issues regarding the school board within his complaint.
  2. During our investigation, we confirmed with the IPC that it was investigating the issue of whether the school board, in making use of Edsby in its schools, had complied with the relevant obligations in MFIPPA regarding the collection of personal information. The IPC’s investigation was ongoing at the time of writing this report.
  3. In light of the IPC’s investigation, we limited the scope of our Office’s investigation to consider whether CoreFour complied with its security safeguards, mandatory breach reporting and privacy accountability obligations. We understand that the IPC’s investigation is examining the complainant’s allegations about the school board’s consent and openness practices regarding Edsby, taking into account the school board’s education mandate, service agreement with the respondent and its direct relationship with students and parents, including the complainant and his children. We further note that CoreFour is a service provider to schools and school boards (as it is to the school board in the IPC’s investigation), with legal obligations to use information only as directed by those clients. We are, therefore, of the view that the allegations regarding consent and openness are more appropriately dealt with in the IPC’s investigation.
  4. The two Offices signed an information sharing arrangement on October 19, 2019. Pursuant to the arrangement, our Office shared relevant information from this investigation with the IPC to inform their investigation. Due to limitations in MFIPPA, the IPC was unable to reciprocate. This is unfortunate, as two-way sharing would have allowed: (i) our Office to benefit from the information gathered by the IPC, as well as their perspectives and analysis in respect of the above matters, and (ii) our two Offices to benefit from a more open collaborative engagement on this matter, the value for which would also be realized by the shared constituents whose privacy rights we are mandated to protect.

Methodology

  1. During the investigation, the respondent submitted several detailed responses to questions raised by our Office. It also provided copies of documents and records including its internal policies and procedures, contractual agreements, information security assessments, the Edsby User Guide, and other relevant operational and communications material.
  2. We also reviewed publicly available information about the respondent and the Edsby platform, including the content of the edsby.com website, third-party reviews and articles about the application, and more general reports about the adoption of education software.
  3. We examined the test environment of Edsby (which “mirrors” the production environment)Footnote 3 in the OPC’s technology laboratory using “dummy” student, parent, teacher and staff administrator accounts provided by the respondent.
  4. Furthermore, we conducted a site visit at the respondent’s office premises, during which we interviewed senior management and operational staff versed in the technical aspects of the company’s privacy and security systems, policies, procedures and practices. We also observed demonstrations of the respondent’s processes and reviewed systems, security alerts, reports, logs and other controls.

The respondent’s position

  1. The respondent contested the complainant’s allegations. It claimed that he came to an unfavourable interpretation of its business practices regarding Edsby, its information security and privacy policies and the content of its privacy policy, based on limited and incomplete information.
  2. While the respondent acknowledged to our Office that the two vulnerabilities raised by the complainant had existed, they were addressed and the parties affected by the profile image vulnerability were informed. The respondent had also been open in its communications with its private school and school board clients about Edsby’s functionality, how it worked with third parties, and various security and privacy issues as they were identified and then resolved.
  3. Furthermore, the respondent indicated that it was taking steps to document its information security and privacy practices as part of its goal of applying for an industry security standard certification.
  4. Finally, the respondent stated that its revenue is exclusively based on fees received from its private school, school board and ministry of education clients. It did not monetize data by sharing or selling user information to other third parties for commercial or non-commercial purposes, or by placing any form of advertising on Edsby.Footnote 4

CoreFour and the Edsby application

  1. In Sept. 2011, the respondent, located in the Greater Toronto Area, launched the Edsby app. At the time of our site visit, Edsby clients included private schools and regional district school boards across North America (Ontario, Alberta and Manitoba in Canada and Florida in the United States). It had also announced its deployment across New Zealand.Footnote 5 The respondent has since launched Edsby in Saskatchewan.Footnote 6
  2. Edsby offers web-based educational services including support for: (i) classroom course content management and tools; (ii) assessment, grading and reporting; (iii) group collaboration; (iv) student and teacher timetabling and calendars; (v) parent-staff engagement; (vi) registrations and workflows; (vii) school and district news; and (viii) analytics and notes.Footnote 7
  3. Edsby operates as a Software as a Service (“SaaS”)Footnote 8 application, with the respondent customizing Edsby to each client’s specifications.
  4. The app is centrally-managed, being integrated and synchronized with a client’s student information system (“SIS”), HR and other structured data sources.Footnote 9 Integration is “bi-directional”. The respondent “pulls” student, teacher, staff, parent, class, timetable and other agreed data elements from a client’s systems and records to authenticate users and ensure Edsby can provide the required services based on accurate and reliable information. Information input directly into Edsby by users during the day can also be “pushed” back through the synchronization process to update the client’s own internal systems and records.Footnote 10 Footnote 11
  5. Through such integration and synchronization, Edsby has access to and handles high volumes of student, parent, teacher and administrative staff information on a daily basis. Users can also input new content into Edsby each school day, including for example, student attendance, class assignment content, evidence of student learning, registration for events, and parent-teacher communications.
  6. The respondent uses a cloud platform managed by a large international cloud provider (the ‘cloud provider’) to host the Edsby application and store data generated by users of the application. This cloud platform claims to adhere to a range of security standards including ISO 27018, the international cloud privacy standard. The data of Edsby’s Canadian clients is held on Canadian-based cloud servers maintained by the cloud provider. A multi-tenancy model for client data is used, and by default, no cross-tenant sharing of data is allowed.Footnote 12 CoreFour’s agreement with the cloud provider requires that customer data be kept confidential and only used for purposes of the business relationship. Subsequent to discovery of the profile image vulnerability, but before the commencement of our investigation, the respondent engaged a third-party security provider (the “security provider”) to provide cloud security services, including a cloud Web Application Firewall, to further protect Edsby cloud servers.
  7. The respondent stated that Edsby is able to integrate with other education apps at the request of its clients through a standard known as Learning Tools Interoperability (LTI). LTI is managed by an independent non-profit organization which supports education technology interoperability.Footnote 13
  8. The respondent explained that it may share certain personal, or other, information with two external Edsby “channel partners” and one “product partner” in Canada, under prescribed circumstances.Footnote 14 Channel partners (e.g., Agents, Value Added Resellers, and Distributors) are granted access to demonstrations of Edsby within its test servers but not to production Edsby systems and, therefore, do not access personal information on Edsby. Product partners are developers of education apps and content solutions chosen by the client for integration into their version of Edsby. The information shared with such applications, and which users get access to what information, is also determined by each client. CoreFour maps its security accordingly.
  9. The respondent’s ability to grant third parties, such as product partners, access to Edsby user information is restricted by the contractual agreements made with its clients, and requires prior written direction and approval from an authorized official of the relevant client school or school board.
  10. There are two Edsby mobile applications: Edsby and Edsby Capture. The Edsby app enables students, parents and teachers to access their Edsby account and use Edsby functions in the same way as they would when accessing via a desktop or laptop web browser. The respondent does not provide an “offline” experience within the Edsby mobile app and thus does not attempt to store significant user information in a mobile device’s local storage, except limited cachingFootnote 15 for performance reasons.
  11. The Edsby Capture app reads QR codesFootnote 16 generated in Edsby Classes. This enables users to take photographs (e.g., of a completed assignment) and then upload the content to the Evidence of Learning stream linked to the class in question. The client’s site name, the ID of the class and of the student, and a date/time authentication ticket are encoded for the limited purpose of uploading the specific item. The photographs taken via the Capture app are not stored in a user’s mobile device. Rather, they upload directly to Edsby.
  12. As part of our review of the apps, we also examined the permissions requested and questioned the respondent about its need for the permissions. The app permissions were consistent with the stated purposes and functionality of each app.
  13. The respondent provides extensive guidance for Edsby users including Frequently Asked QuestionsFootnote 17, “help files” user videosFootnote 18 and product newsFootnote 19 on its website, plus additional material for its private school and school board clients including Product Updates and a detailed Edsby User Guide.

The adoption and onboarding of Edsby by the school board

  1. The school board cited in the complainant’s allegations is a large Ontario-based school board with over 120,000 students attending more than 200 schools. It selected the Edsby application in August 2016, pursuant to a Request for Proposals process. The respondent explained that the school board took a cautious approach to its adoption and onboarding of Edsby, using pilot programs. Its four year rollout plan began in the Fall of 2016:
    1. The 2016-2017 school year was spent configuring and tailoring Edsby to meet the school board’s requirements;
    2. In 2017-2018, the Parent-Teacher interview booking system went live. This was followed by the gradual rollout of the Attendance service at certain of the boards’ schools;
    3. The 2018-2019 school year saw the introduction of the Evidence of Learning and Communication of Learning tools within certain kindergarten classes. Select schools also ran pilots of the Edsby Report Card service;
    4. 2017-2018 and 2018-2019, saw the launch of registration campaigns including Kindergarten, International Languages and Summer Institute registrations; and
    5. 2019-2020 saw a wider rollout of Edsby’s Assessment and Reporting tools, and the deployment of Edsby’s Attendance service at the board’s high schools.
  2. The respondent explained the Edsby client onboarding process to our Office in detail. This process can take up to a year. The school board was onboarded via this standard path. In summary, CoreFour works closely with the client prior to roll-out of the application, including by:
    1. customizing Edsby to the client’s specific needs, such as: (i) determining what information will be pulled from the client’s existing systems and what data will be “pushed” back; and (ii) determining the appropriate user permissions;
    2. testing the configuration with fictional data, making an external offline sandboxFootnote 20 server available to its clients;
    3. verifying the integration between Edsby and the client’s systems, structured data and requested education apps; and
    4. providing training to client staff using the Edsby test environment or sandbox.
  3. The school board and respondent initially entered into two agreements with respect to Edsby: (i) a Contract Agreement for Services (the “service agreement”): and (ii) a Confidentiality and Personal Information Agreement (the “personal information agreement”). We note that the agreements require the respondent and its vendors and sub-vendors to be compliant with PIPEDA.
  4. In January 2018, the school board asked an independent IT auditor (the “IT auditor”) to assess the respondent’s information security and privacy practices for Edsby (the “assessment”). After the issuance of certain recommendations by the IT auditor, the board and the respondent entered into a letter of amendment (the “letter of amendment”) that contained new conditions concerning the security and privacy protection of the board’s data. The extensive conditions in the letter of amendment confirm, among other things, that all data in Edsby regarding the board’s programs, students and others belongs to the school board. The respondent cannot use students’ personal information for its own benefit, nor can it create and maintain data derived from the data, except for the purpose of performing its obligations under its agreements and as authorized by the school board. Further conditions state that the respondent can only give access to, or disclose data to, third parties with the prior consent of the school board and subject to certain terms. The board can also require the return or destruction of data held by the respondent or any third party acting for the respondent at its request.
  5. At the time of our site visit, the respondent stated that the IT auditor was the only third party the board had authorized to be granted access to Edsby.

Issue 1: Safeguards

  1. Pursuant to Principle 4.7 of Schedule 1 of PIPEDA, an organization is required to ensure that personal information is “protected by security safeguards appropriate to the sensitivity of the information.”
  2. Principle 4.7.1 states that security safeguards shall protect personal information against loss or theft, as well as unauthorized access, disclosure, copying, use, or modification, and that organizations shall protect personal information regardless of the format in which it is held. Principle 4.7.2 adds that the nature of the safeguards will vary depending on the sensitivity of the information collected, the amount, distribution, and format of the information, and the method of storage. Sensitive information should be safeguarded by a higher level of protection.
  3. Principle 4.7.3 stipulates that the methods of protection should include: (a) physical measures, for example, locked filing cabinets and restricted access to offices; (b) organizational measures, for example, security clearances and limiting access on a “need-to-know” basis; and (c) technological measures, for example, the use of passwords and encryption.
  4. As detailed below, overall, our investigation found that the respondent had implemented many good security practices. We confirmed, however, that the complainant’s allegations about specific security vulnerabilities (weak parental passwords and access to images of student profile pictures) were accurate. We also identified another vulnerability associated with the uploading of documents to Edsby. Ultimately, we determined that the respondent lacked an overarching information security framework. In our view, had the respondent implemented such a framework, it could have mitigated, and potentially avoided, the vulnerabilities identified.
  5. As a result of the above, we recommended that the respondent implement certain measures to bring it into compliance with its security safeguard obligations under PIPEDA. As outlined under the “Response to the recommendations” section below, the respondent accepted these recommendations, and has either already implemented, or is in the process of implementing, them.

Sensitivity of personal information

  1. The respondent collects and retains significant personal information of children such as student names, dates of birth, student ID numbers, student pictures, details about their parents and where they live, schools the student attends, attendance and absence records, medical information (such as allergies), school assignments, test results and report cards, among other things.
  2. Certain elements of this information, such as medical information or report cards, may be sensitive in and of itself.
  3. Furthermore, we note that much of the personal information accessed and processed by the respondent within Edsby is predominantly about individuals that comprise a vulnerable group: from young children attending kindergarten to teenagers attending high school.
  4. The information associated with a student in Edsby, when taken together, could create rich profiles, which could in turn be used in inappropriate hands to track children online for the purposes of serving behavioural advertising, or in more malicious instances, to target or even endanger children.
  5. The volume of the personal information handled by the respondent is substantial and includes that of hundreds of thousands of students and their parents. This information continues to grow as the respondent adds new Edsby clients and users, and existing clients and their users avail themselves of further Edsby functionality.
  6. Given the volume and sensitivity of the personal information collected, used and disclosed by Edsby, the information should be protected by a high level of security safeguards.

Password management policy

  1. When parents were informed that their children were registered on Edbsy and were invited to set up Edsby parental accounts, the complainant noted that it was possible to open an account with a password as short as a single character. He suggested to the school board and the respondent that the passwords for such accounts should have a required minimum length.
  2. The OPC’s Guidelines for identification and authenticationFootnote 21 state, in part, that organizations should avoid weak authentication processes, for example, by requiring individuals to create passwords that are difficult to guess, e.g., that exceed a minimum length and complexity.
  3. The respondent explained to our Office that its clients treat parents as designated ‘contacts’ of students until they feel ready to invite them to participate in Edsby. Invites are sent to the parents’ email addresses drawn from the ‘contact’ records. Parents can open an Edsby parental account, which is linked to their child’s student account, enabling the parents to see certain content, e.g., their child’s activities, assignments and grades. If a parent chooses not to accept an invitation, the parent remains a simple ‘contact’ of their child.
  4. The respondent provides user accounts for students, parents, teachers and staff of each school or school board that chooses to deploy Edsby. Edsby integrates with a client’s existing authentication system such as Active DirectoryFootnote 22, rather than storing and authenticating passwords directly in the application. The educational organizations manage the password standards that apply in these cases.
  5. The respondent stated that it does not manage or authenticate 95% of Edsby user accounts. Of the remaining user accounts managed and authenticated in Edsby by the respondent, approximately 90% are parental or guardian accounts.
  6. The respondent estimated that at the end of 2017, it managed approximately 150,000 Edsby passwords across all of its clients. By June 2019, around 40,000 parental accounts had been set up in Edsby at the request of the school board.
  7. The respondent confirmed that passwords managed by Edsby are not stored in a clear-text format, but are individually salted and hashed, i.e., they are cryptographically modified in such a way that they cannot be analyzed for length or other characteristics.
  8. That said, the respondent acknowledged the existence of the vulnerability raised by the complainant. In April 2018, it addressed the vulnerability, by deploying a software change that implemented stricter NIST-aligned password standards and controls for all new Edsby-managed passwords.Footnote 23
  9. However, at the outset of our investigation, the respondent had not yet changed the rules for existing passwords or updated the relevant program code for NIST compliance. The respondent confirmed its intention to push a reset of passwords for existing user accounts where it was the authentication authority. Users who had potentially established a weak password would be required to set up a stronger password to comply with the NIST standard before they could access their account.
  10. This reset took place in the Fall of 2019 and the enhancement to password management controls was communicated to all Edsby clients in an online product newsletter.Footnote 24
  11. We are of the view that the respondent’s management of Edsby parental account passwords was inadequate given the amount and sensitivity of the information under Edsby’s control, and raised the potential risk of individuals gaining access to the information held in Edsby, a vulnerability which remained for approximately 18 months, until changes were implemented to require stronger passwords for existing accounts.

Images of student profile pictures

  1. When accessing Edsby, the complainant was able to gain access to thumbnail images of student profile pictures of children other than his own, who were attending schools within the same district.Footnote 25 The complainant viewed the other thumbnail images through his Internet browser by iterating through the file names for individual images, which took the form of sequential identification numbers.
  2. In January 2019, the complainant notified the principal of his children’s school about the vulnerability and sent a small sample of the thumbnail images of other students he had been able to access as evidence. The school board in turn informed the respondent. The school board and the respondent later met the complainant to discuss this and other security and privacy concerns he had. The respondent claimed that when the complainant was asked about the nature of the vulnerability, he refused to provide an explanation.
  3. The respondent estimated that in January 2019, approximately 120,000 students enrolled with the school board had thumbnail images of student profile pictures in Edsby. The respondent noted that while not all clients choose to upload such images to Edsby, where clients choose to do so, the methodology for including them is the same. Therefore, this vulnerability potentially existed for other Edsby clients.
  4. The respondent stated that January 2019 was the first time it became aware of the vulnerability. In its investigation of the issue, it confirmed that thumbnail images of student profile pictures were involved. No original high resolution pictures of students, and no other student information, such as names or dates of birth, were at risk.
  5. The respondent explained that it used one approach for handling normal file and picture storage and a completely separate approach for handling thumbnail images. It used thumbnail images for the purpose of allowing a social style user interface that provides the images, in this case pictures of students, in various parts of the Edsby user experience. Normal file storage and handling is managed via Edsby access controls. Thumbnail images handling is separate, with file names treated as keys.
  6. The respondent examined the Edsby server log files going back to August 2017. It identified that the complainant accessed these thumbnail images a limited number of times over a 14-month period between November 2017 and January 2019. According to the respondent, the complainant was the only individual who had done so, and he had downloaded a total of 163 images. Only images of pictures linked to students registered with the school board were involved.
  7. The respondent explained that it made immediate changes to the Edsby production environment to reduce the potential for the vulnerability to be exploited. It then created and deployed a more permanent fix to the production environment on January 23, 2019, replacing the sequential file numbers of the images with globally unique identifiers.Footnote 26
  8. During our site visit, the respondent’s development team demonstrated to our technical analysts that it was no longer possible to access the images in the Edsby production environment by modifying the file names.
  9. In our investigation, we found that the thumbnail images of student pictures in the production environment had been held in a shared directory to which all authorized Edsby users at the school board had access. Furthermore, access controls within Edsby were not granular to the file level, and there had been no web application firewall in place when the vulnerability was reported by the complainant. Therefore, it would have been possible for another third party with user access to iterate through the images and collect them without detection, as the complainant did.
  10. Exploitation of the vulnerability would have required an individual to have access to Edsby, to view and collect the images. We note that no other student data was linked to the images. However, the number of images potentially accessible through the vulnerability exceeded 120,000 and they were of children. Further, the vulnerability existed for some time and was identified by a third party who was able to access the images or pictures over a 14-month period without being detected.
  11. The respondent’s use of sequentially numbered file names, their display in file URLs and the lack of a web application firewall did not adequately protect these images from unauthorized access.
  12. That being said, the respondent addressed the vulnerability promptly after learning of it. The use of globally unique identifiers along with the introduction of a web application firewall and intrusion detection system will help prevent future unauthorized access.

Information security framework

  1. The complainant alleged that the respondent did not appear to have an adequate information security framework, resources, policies and standards in place to protect the large volume of sensitive personal information held in Edsby.
  2. In addition to Principle 4.7 to 4.7.3 (detailed above), Principle 4.1.4 of PIPEDA requires that organizations implement policies and practices to give effect to the principles, including implementing procedures to protect personal information. Documenting security policies and implementation plans provides clarity about expectations and requirements; ensures consistency and helps an organization to identify and manage information security risks. In that sense, proper documentation and associated training is a crucial safeguard in and of itself.
  3. During the investigation, the respondent provided extensive information about its information security architecture and responded to the detailed information security questions we raised.Footnote 27
  4. The respondent informed our Office regarding the IT auditor’s assessment of Edsby, in early 2018 at the request of the school board. The assessment examined: (i) the operational security of the internal Edsby network; (ii) the respondent’s physical and environmental security; (iii) systems acquisition, development and maintenance; (iv) supplier relationships, and; (vi) information security incident management. The assessment included a site visit to the respondent’s business premises and testing of its security controls.
  5. We examined a copy of the assessment, wherein the IT auditor identified certain recommendations for improving the security and privacy of the school board’s data in Edsby.
  6. We determined that the specific technical issues identified by the auditor were addressed promptly, and the vulnerability scanning and penetration testing of Edsby was improved and formalized. The privacy-related recommendations were addressed via the letter of amendment outlined in paragraph 34.
  7. However, the assessment found that the respondent did not have a formal information security policy in place, instead relying on a consensus around “best practices” to guide its overall approach. It recommended that the respondent implement and follow such a policy aligned with a recognized industry security standard.
  8. The respondent also lacked a formal governance structure with no single person designated to be responsible for information security, or to liaise with external third parties to ensure that Edsby information is secure. The assessment report recommended that this also be addressed.
  9. The IT auditor further noted, at the time, that the respondent did not have a documented breach response strategy or plan, or a designated person or team responsible for detecting, or responding to, information security alerts and incidents.
  10. During our own investigation, we found that the respondent’s information security procedures continued to be informal in nature and documentation was limited. However, the respondent indicated that it was committed to achieving an industry security standard, and was in the process of defining, reviewing and documenting its procedures. Later, in response to our recommendations, the respondent specified that it was in the process of seeking ISO 27001 certification.
  11. We further observed that a considerable amount of information and knowledge about the respondent’s information security operations, and the responsibility for managing them, appeared to reside with a single employee. This was evident to our investigation team during our site visit, when we consistently had to bring in the employee into interviews to answer technical questions that other employees should have been able to answer as part of their designated roles. The lack of sufficient back-up information security resources, segregated responsibilities for such operations and the limited documentation surrounding information security operational procedures represent an important gap in the respondent’s safeguard practices.
  12. While the respondent provided our Office with updated versions of its draft policies and procedures comprising its information security framework, those we saw were still in development and had yet to be finalized.
  13. The respondent’s lack of written processes, procedures or templates comprising an overarching information security framework contravenes Principle 4.1.4, as well as Principles 4.7 to 4.7.3 of PIPEDA. We note that while work on the framework (first recommended in the 2018 assessment) continues, it had still not been completed at the time of writing this report.

Other security matters

  1. We also conducted an assessment of various other specific security safeguards adopted by the respondent. We observed several good security practices, as well as one further vulnerability, as detailed below.
  2. The respondent currently uses a third-party security provider for several security services, including a web application firewall and an intrusion detection system to protect the Edsby cloud servers against external threats. The security provider’s professional services team manages all aspects of security. Email notifications are sent to the respondent upon alerts, and the respondent’s personnel view the alerts on the security provider’s dashboard.
  3. Subsequent to the respondent’s engagement of the security provider referred to in paragraph 23, external penetration testing of Edsby is now conducted on at least an annual basis and we found our attempts to penetrate the application were consistently blocked by the security provider’s firewall. The respondent also received several security alerts that led to their blocking of our test accounts.
  4. Access to Edsby by users at the school and school district level is hierarchical, account-based and driven by each client’s requirements. Every user account is assigned a defined role and each role represents a set of permissions and privileges within Edsby which permit users to retrieve and view information within the application. Edsby also works on a link-based system which determines the relationship between accounts, e.g., the link between a parent’s account and their child’s student account, or a teacher’s link to a student account where the student is taught by the teacher.
  5. Authorization and user authentication services are based on a client’s own credential system typically used in their SIS. Each client has the ability to establish and control user roles, permissions, access and group memberships within Edsby.
  6. CoreFour had various measures in place to limit internal access and ensure confidentiality. The respondent requires its employees, contractors, consultants and interning students to sign a non-disclosure agreement to protect the confidentiality of information belonging to the organization and its clients. Direct access to Edsby user information is further restricted to a small sub-group of employees in the software development and customer support teams for defined purposes, e.g., troubleshooting client problems. These employees must sign an additional personal information agreement. No contractor, consultant or student is granted access to such information. The respondent also logs internal access to its systems and Edsby at all times and monitors the logs regularly.
  7. The respondent also logs user interactions within Edsby, which are then regularly reviewed by the respondent through the use of reporting tools, to ensure that users are not engaging in practices that represent a security threat, or are contrary to its terms of use. Rules for system monitoring are controlled internally and monitored by the respondent to ensure that they are working as intended and that appropriate alerts are generated.
  8. While the above represents what we would consider to be good security practices, we did identify an issue with how Edsby uploads data used by its clients, from email and storage solutions such as Google Workspace (formerly Google G Suite) and Microsoft Office 365. Where clients authorize this, the data is imported “as is” into Edsby, with CoreFour relying on such third-party solutions having already scanned the data for malware content. While such providers may have already scanned the data, the respondent should not rely on this. If such third-party scanning did not take place or failed for any reason, then Edsby could be potentially compromised.
  9. The lack of scanning of such potential security threats to Edsby therefore represented, in our view, a further safeguard weakness and contravention of Principle 4.7 of Schedule 1 of PIPEDA. In response to a recommendation by our Office, outlined below, CoreFour confirmed that it had addressed this issue in 2020.

Safeguards – Recommendations

  1. Taking into account the information security issues and contraventions of PIPEDA highlighted above, we recommend that the respondent implement certain measures, to bring it into compliance with its safeguards obligations under Principle 4.1.4 and Principles 4.7 to 4.7.3 of Schedule 1 of PIPEDA, within 6 months of the issuance of this report:
    1. Complete and implement its information security management framework, as a priority, including all written technological policies, procedures, processes and templates;
    2. As part of the above management framework, implement measures to ensure it has sufficient back-up human resources for IT security, and has mapped out an appropriate segregation of IT security responsibilities;
    3. Conduct its own scans for malware when importing content into Edsby from other third party software applications; and
    4. Train its staff on the policies, procedures and measures undertaken in response to recommendations a) to c) above.
  2. We further request that the respondent provides our Office with a report from a qualified and independent third party documenting the measures it has taken to comply with the above recommendations.

Issue 2: Breach reporting and notification

  1. For the reasons set out below, we found that the respondent did not contravene PIPEDA’s mandatory breach reporting, notification and record-keeping provisions.
  2. As detailed below, we found that in the case of the password management vulnerability, no actual breach occurred. In any event, at the time, breach reporting by private sector organizations was not yet mandatory under PIPEDA. The respondent was therefore, under no specific PIPEDA obligation to notify parents, or our Office, of the vulnerability.
  3. As further explained below, when the complainant notified the respondent of the student image vulnerability, mandatory breach reporting and notification had come into effect under PIPEDA. However, we found that the only breach associated with this vulnerability flowed from the complainant’s own actions, which in our view, did not result in a real risk of significant harm, such that the respondent was not required to report the breach to our Office or notify affected parents. Finally, we found that the respondent had appropriate breach reporting procedures and maintained a breach register as required under PIPEDA.

Obligation to report breaches and notify those affected

  1. Prior to November 1, 2018, breach reporting and notification by organizations subject to PIPEDA was voluntary. From that date, organizations became subject to mandatory breach reporting, notification and record-keeping obligations under sections 10.1, 10.2 and 10.3 of PIPEDA and the associated Breach of Security Safeguard Regulations.Footnote 28
  2. Section 10.1 of PIPEDA states, in part, that an organization shall report to the Privacy Commissioner of Canada any breach of security safeguards involving personal information under its control, if it is reasonable in the circumstances to believe that the breach creates a real risk of significant harm to an individual. The section adds that an organization shall also notify affected individuals about those breaches. Section 10.2 states that an organization must notify any other organization that may be able to mitigate harm to affected individuals. Section 10.3 states that an organization shall keep and maintain a copy of every breach of security safeguards involving personal information under its control and shall, on request, provide the Privacy Commissioner with access to, or a copy of, a record.
  3. Our Office has issued guidance regarding What you need to know about mandatory reporting of breaches of security safeguards (the “breach guidance”).Footnote 29 The breach guidance notes that, in accordance with section 10.1 of PIPEDA, the obligation to report a breach rests with the organization “in control” of the personal information implicated in the breach. Therefore, an organization that is processing personal information purely on behalf of another organization is typically not required to report the breach.
  4. The IT auditor’s 2018 assessment included a recommendation that the respondent introduce a plan to ensure a rapid and effective response to any privacy breach and that the plan include a requirement to notify the school board in the event of a suspected or real breach of school board data. The respondent provided our Office with a copy of its October 2018 breach reporting procedures and breach register, which it created in response to the IT auditor’s recommendation.
  5. We note that the November 2018 letter of amendment also contains terms regarding the respondent’s requirement to inform the school board of any suspected or real breaches and to cooperate with the board in any resulting investigation and disclosures to affected parties.
  6. The respondent is acting as a service provider to the school board. Consistent with our breach guidance, referenced in paragraph 99 above, this raises the question of whether CoreFour was in control of the personal information at issue for the purposes of s. 10.1 of PIPEDA and whether it was responsible for reporting the breach in question. We are of the view, however, that we need not make a determination on this issue for the reasons that follow.

Reporting and notification: the password management vulnerability

  1. The respondent and the school board were informed about the password management vulnerability in November 2017. The respondent’s review did not identify any unauthorized access of Edsby, nor did it find any loss, collection or disclosure of user personal information. The respondent addressed the issue for new accounts in April 2018, and existing accounts in the Fall of 2019, and informed all its Edsby clients of new password rules in a December 2019 newsletter.
  2. We have no evidence that this vulnerability resulted in a breach. Furthermore, breach reporting by organizations governed by PIPEDA was voluntary until November 2018, one year after the complainant notified the respondent of the password vulnerability.

Reporting and notification: the student profile picture vulnerability and breach

  1. The complainant notified the respondent and school board of the student profile picture vulnerability in January 2019, after mandatory breach reporting under PIPEDA came into effect.
  2. The respondent stated that the school board assumed immediate management of the breach, as the owner of the students’ information in Edsby. Concurrently, the respondent immediately sought to address the vulnerability and safeguard the data.
  3. The respondent asserted that there was no real risk of significant harm to the students involved, as only thumbnail images of student profile pictures were exposed, without any other identifying information. The respondent also examined its access logs going back to August 2017 and identified that the only breach that occurred as a result of the vulnerability was the unauthorized access and collection of 163 images by the complainant.
  4. The respondent assisted the school board in identifying the children whose images were accessed without authorization, and their parents. The school board sent each of the affected parents a letter to notify them of the breach and issued a general notification of the breach on its website.
  5. The respondent explained that it proactively notified its other Canadian clients of the breach through Edsby Product Update 106, issued in February 2019.
  6. The respondent claimed that the above communications went beyond the obligation to notify affected parties required under PIPEDA’s mandatory breach reporting provisions.
  7. The breach guidance states that factors relevant to determining whether an organization has suffered a breach that created a real risk of significant harm include: (i) the sensitivity of the personal information involved; and (ii) the probability the personal information has been/is/will be misused.
  8. Although the picture of a child, without the presence of any other identifying information, could be considered by some as not necessarily sensitive, our Office has tended to consider the personal information of minors, a vulnerable group, as generally sensitive in nature.
  9. That said, in analyzing the probability of harm arising from this breach, we recognize that the complainant was a parent with legitimate and existing access to the application and was an individual already known to the respondent and the school board. The complainant accessed a limited number of thumbnail images of student pictures and presented a small sample of these to four school board officials, including his children’s school principal, to inform the school board and the respondent about a security vulnerability within Edsby. While the complainant also published a number of these images on a closed Facebook page accessible to certain parents of children at his children’s school, the images were blurred. The complainant did not pass the images on to an unauthorized third party, only to the school board. The complainant also confirmed to our Office in writing that he had destroyed all of the images in his possession in February 2019. In our view, therefore, there was a low likelihood of harm to the affected students or their parents.
  10. Having assessed the above factors, in our view, the breach of the images did not represent a real risk of significant harm to the students, such that no breach report would have been required.
  11. As outlined in paragraph 102, we have not determined whether the respondent, as a service provider, would generally be required to report such a breach even if there were a real risk of significant harm. That said, in any event, the school board did in fact notify the parents of the affected children. It also brought the incident to local police, who investigated the matter and interviewed the complainant, but decided not to pursue further action.
  12. The respondent stated that to its knowledge, no other privacy breach (meeting the real risk of significant harm criteria or otherwise) involving the school board or its other clients has taken place. Therefore, its privacy breach register only contained information regarding the profile picture vulnerability.
  13. Taking into account the above, we are satisfied that the respondent did not contravene the breach reporting and notification provisions under sections 10.1 to 10.3 of PIPEDA, with regard to the password management vulnerability and the student image vulnerability.

Other: the security provider breach

  1. During the course of our investigation, the complainant informed our Office about a security breach at the third-party security provider which supplies cloud security services to the respondent and its Edsby application.Footnote 30
  2. While this event was outside the scope of our investigation, we raised this matter with the respondent and asked if it was one of the web-application firewall clients whose information had been compromised by the breach. We also asked if the breach had an impact on Edsby’s security.
  3. The respondent informed us that it noticed the breach announcement the day it came out, and quickly engaged with the security firm. The respondent recognized that the potential risk to Edsby’s security was, in theory, serious. It engaged with the security provider to obtain more information about the breach, and find out if the breach had affected its operations. On completing its analysis, the respondent confirmed that no Edsby customer data was at risk. Nevertheless, the respondent implemented all of the risk mitigation steps advised by the security firm and released a summary of its findings to all of its clients in a special Product Update.Footnote 31

Issue 3: Accountability

  1. During our investigation, we reviewed the respondent’s internal privacy policies and procedures, risk assessment practices, privacy training, and Privacy Policy for Edsby.
  2. In doing so, we considered principle 4.1.4 of Schedule 1 of PIPEDA and the document Getting Accountability Right with a Privacy Management Program, which guides organizations on constructing a privacy management program to demonstrate compliance with their accountability obligations.Footnote 32
  3. Principle 4.1.4 states that organizations shall implement policies and practices to give effect to the principles, including: (a) implementing procedures to protect personal information; (b) establishing procedures to receive and respond to complaints and inquiries; (c) training staff and communicating to staff information about the organization’s policies and practices; and (d) developing information to explain the organization’s policies and procedures.

Policies, procedures and controls

  1. The respondent explained that while its internal privacy policies and procedures were informal and unwritten, they were largely driven by their clients’ requirements.
  2. For example, the respondent explained that it did not have a data retention and destruction policy, procedure and schedule. While Edsby holds extensive personal information about students, parents, teachers and administrative staff of its clients, the clients are the owners and controllers of the data under their service agreements with the respondent. Therefore, each client sets out the parameters as to what user information is retained within Edsby, how long it is retained and for what purposes, based upon the applicable education and privacy laws.
  3. The respondent explained that at the end of each school year, Edsby marks all user accounts as inactive. At the start of the next school year, the respondent “pulls” information from a client’s SIS and other data sources to determine what new user accounts must be created and what existing accounts can be pulled out of the archive, amended and reactivated. This process ensures that a client’s user accounts are each year, by default, archived and old accounts do not remain active within Edsby. Archived accounts may be accessible to designated staff as determined by each client, e.g., a school administrator may need access to student report card data from the previous school year even though a student account may no longer be active or generally accessible.
  4. The respondent stated that in the school board’s case, the deletion of user information or an account requires the written permission of a senior official of the school board, and once deleted, the respondent must provide a copy of a certificate of destruction to the board.
  5. Notwithstanding the above, it was unclear to our Office how the respondent could provide appropriate privacy support to its clients, as required by its contractual agreements, without adequate internal privacy policies and procedures.
  6. During the investigation, the respondent recognized the need to develop and document internal privacy policies and procedures consistent with PIPEDA. It indicated its intention to create complaint handling and data retention and destruction procedures. At the time of writing this report, our Office had not received a copy of these procedures.
  7. The respondent also confirmed that while it had not conducted a formal assessment of the privacy risks within the Edsby application, it had answered questions concerning its management of such risks when responding to clients’ due diligence questions.
  8. While we recognize that such assessments are not an explicit requirement under PIPEDA, the Getting Accountability Right with a Privacy Management Program guidance recommends that organizations, as a “best practice”, develop a process for identifying and mitigating privacy and security risks prior to a product’s launch, or before substantive changes are made to a product.Footnote 33 Designing for privacy at the front end is an important part of a privacy management program. We see this practice to be particularly important in the context of an organization like CoreFour, that handles such a large amount of potentially sensitive personal information.

Privacy training

  1. The respondent acknowledged that it did not provide formal privacy training to its staff and could not provide a copy of any privacy-related training material. However, it explained that all employees who signed the personal information agreement were briefed on the appropriate handling of user information.

The Edsby Privacy Policy

  1. The complainant claimed that the respondent’s privacy policy mischaracterized personal information, indicated that the respondent refused to accept responsibility for the security of the personal information in its custody, and was unclear about its sharing of user information with others.
  2. The respondent explained that Section 1 of its privacy policy describes the types of information that Edsby collects and stores about a user: (i) Your Personal Information; (ii) Content You Provide; and (iii) Information Related to Your Usage of the Site. The respondent stated that it wanted to be transparent and provide users with insight about the information it collects. It did not intend to confuse users or imply that the latter two types of information cited do not constitute personal information.Footnote 34
  3. We reviewed the privacy policy and agree that its description of the information collected could be confusing. By referring to the first type as “your personal information” the policy implies that the other information collected is not personal information. Yet certain data elements listed under the last two typesFootnote 35 would, in our view, be considered personal information as defined under PIPEDA. We recommend that the respondent revise the content of this section to avoid potential confusion.
  4. The complainant also expressed concern about the respondent’s alleged sharing of user information with employees, consultants, contractors and any subsidiary and parent companies described in Section 2 of the policy.Footnote 36 In addition, he pointed to text stating the respondent could “…transfer the information we collect and store and all associated rights as an asset in connection with a merger or sale…involving all or part of our business or as part of a corporate reorganization, stock sale or other change in control…”
  5. Firstly, we note that the respondent has no parent or subsidiary companies. Furthermore, we accept that it is reasonable for the respondent to share Edsby user information with its authorized employees, consultants and contractors for the purposes of providing technical support to Edsby clients and their users, subject to appropriate contractual arrangements and safeguard measures.Footnote 37
  6. The privacy policy also clearly states that the respondent may share Edsby user information with third-party software providers. We observed that such sharing is only allowed under the direction and written approval of an authorized senior member of the relevant Edsby client, which has selected a provider to help implement its education mandate.
  7. Finally, subsections 7.2(1) and 7.2(2) of PIPEDA allow an organization to use or disclose personal information, without the knowledge or consent of an individual, where it forms part of a prospective or completed business transaction (subject to certain limitations). Notwithstanding this, we note that the contractual agreements between the respondent and the school board require Edsby to notify the school board of any such proposed transfer, and where the school board does not agree to the transfer, it can request that user information in Edsby be returned or destroyed.
  8. The complainant claimed that the respondent also refused to accept responsibility for the security of the personal information in its custody in Section 7 – Disclaimers of the privacy policy:

    “No security measures are perfect. We cannot guarantee or warrant the security of any information you provide to us or that we store on your behalf.

    We cannot guarantee that only authorized people will have access to the information and content we store and display about you. We are not responsible for real or perceived breaches in our security caused by third parties violating our Terms of Use. For example, our Terms of Use state that a user agrees they will only use the Service to access their own account. However, a common security “breach” in many computer systems occurs when one user finds out another’s password and uses that to access an account other than their own in clear violation of the Terms of Use…” [Emphasis added]

  9. The respondent explained that it was not denying responsibility for any privacy breaches. Rather, it was explaining that it was not responsible for privacy breaches caused by an individual violating the Edsby Terms of Use.
  10. While an organization cannot absolutely guarantee the protection of personal information in its possession or control, PIPEDA requires that an organization have appropriate safeguards in place to protect the information, commensurate with the sensitivity of the personal information it holds. We therefore recommend that the respondent revise this section of the privacy policy to remove references denying responsibility for any or all privacy breaches.

Accountability – recommendations

  1. Taking into account the respondent’s lack of a privacy management framework, including written privacy policies and procedures, and appropriate privacy training of its personnel, we are of the view that the respondent has contravened principle 4.1.4 of Schedule 1 of PIPEDA.
  2. We recommend, therefore, that the respondent develop and adopt, as a priority but in any event by 6 months from the issuance of this report, a privacy management framework, in addition to the information security framework recommended above, consistent with its obligations under PIPEDA. We recommend that the framework include:
    1. Development and documentation of privacy policies and practices to give effect to the principles, including with respect to: (i) managing and resolving privacy-related inquiries and complaints; and (ii) managing the retention and destruction of personal information held by the company.
    2. Adoption and documentation of a privacy-training program that ensures that all individuals employed or otherwise engaged by the respondent are informed of and understand the organizations policies and practices. Such training should be provided both when individuals are first employed or engaged and at regular intervals thereafter.
  3. We also recommend that the respondent address the following matters by updating its Privacy Policy:
    1. Amend Section 1 to better explain, and avoid confusion concerning, the personal information that it collects, uses and stores about Edsby users; and
    2. Amend Section 7 to better explain that it is not denying responsibility for any and all privacy breaches that may occur in Edsby.
  4. Finally, we request that the respondent provide our Office with a report from a qualified and independent third party documenting and confirming the measures it has taken to implement the recommendations in paragraph 144-145.
  5. In addition to the above recommendations, we also encourage the respondent, as a “best practice”, to develop a risk assessment process identifying and mitigating privacy risks arising from its ongoing development of Edsby.

Response to the recommendations

  1. CoreFour accepted our recommendations, as outlined in paragraphs 92 and 144-145, and committed to implementing them within the 6-month deadline.

Response to safeguards recommendations

  1. CoreFour responded that it was making progress on completing and implementing an information security management framework, having engaged an information security consulting firm in 2020, to assist in preparing for ISO 27001 certification. It expected to be ready for ISO external audit by the end of June 2021.
  2. CoreFour stated that, as part of its preparation for ISO 27001 certification, it would allocate sufficient back-up human resources for IT security, via the addition of dedicated personnel in key roles including information security, and map out an appropriate segregation of IT security responsibilities.
  3. CoreFour also explained that it had released an integrated malware scanning service within Edsby in 2020. All of its clients now had this facility automatically turned on for all external file uploads.
  4. Finally, CoreFour confirmed that it would train its staff on the information security policies, procedures and measures introduced in support of the above recommendations, as part of the ISO 27001 certification process.

Response to accountability recommendations

  1. CoreFour committed to implement a privacy management framework, including the development and documentation of privacy policies and practices and the introduction of an internal privacy training program. CoreFour stated that it was well advanced in implementing these recommendations as part of its ISO certification process.
  2. CoreFour also agreed to make the recommended changes to its Privacy Policy by the agreed deadline.
  3. CoreFour stated that it would also be embedding the development of a risk assessment process into its ISO 27001 processes and procedures.

Compliance report from an independent third party

  1. Finally, CoreFour agreed to provide our Office with a copy of the ISO auditor’s report, as well as a report from a qualified independent third party, to confirm that the measures implemented by CoreFour, including via the ISO 27001 certification process, have fully addressed our recommendations.

Conclusions

  1. We therefore find the safeguards and accountability matters to be well-founded and conditionally resolved, and the breach reporting and notification matter to be not well-founded.
  2. Our Office has a continuing interest in ensuring that CoreFour implements the measures needed to bring it into full compliance with the Act. As such, we will be closely monitoring CoreFour’s progress in the implementation of our safeguards and accountability recommendations.
Date modified: