GDPR Support (Later) (UXPROD-1641)

[UXPROD-2871] GDPR Security of processing Created: 19/Jan/21  Updated: 13/Apr/23

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: GDPR Support (Later)

Type: New Feature Priority: TBD
Reporter: Julian Ladisch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: gdpr
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-2642 GDPR Data protection by default Open
Epic Link: GDPR Support (Later)
Development Team: None
Kiwi Planning Points (DO NOT CHANGE): 12
Rank: Chalmers (Impl Aut 2019): R1
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: GBV (MVP Sum 2020): R1
Rank: U of AL (MVP Oct 2020): R4

 Description   

GDPR Article 32 (Security of processing) requires:

Taking into account

  • the state of the art,
  • the costs of implementation and
  • the nature, scope, context and purposes of processing as well as
  • the risk of varying likelihood and severity for the rights and freedoms of natural persons,

the controller and the processor shall implement appropriate

  • technical and
  • organisational measures

to ensure a level of security appropriate to the risk.

Details
See https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/security/ for details, ico.org.uk wrote this before Brexit and it reflects European Union GDPR requirements. Topics:

  • What does the UK GDPR say about security?
  • Why should we worry about information security?
  • What do we need to protect with our security measures?
  • What level of security is required?
  • What organisational measures do we need to consider?
  • What technical measures do we need to consider?
  • What if we operate in a sector that has its own security requirements?
  • What do we do when a data processor is involved?
  • Should we use pseudonymisation and encryption?
  • What are ‘confidentiality, integrity, availability’ and ‘resilience’?
  • What are the requirements for restoring availability and access to personal data?
  • Are we required to ensure our security measures are effective?
  • What about codes of conduct and certification?
  • What about our staff?

See also https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-by-design-and-default/ :

What are we required to do?

creating (and improving) security features.

Who is responsible for complying with data protection by design and by default?

your senior management, eg developing a culture of ‘privacy awareness’ and ensuring you develop policies and procedures with data protection in mind;

your software engineers, system architects and application developers, –eg those who design systems, products and services should take account of data protection requirements and assist you in complying with your obligations; and

your business practices, eg you should ensure that you embed data protection by design in all your internal processes and procedures.



 Comments   
Comment by Björn Muschall [ 08/Sep/21 ]

I think that with this requirement it is advisable to separate the different levels of responsibility for implementing the "appropriate measures". There is of course, the level of software code and also organizational measures that play a role in the FOLIO development life cycle. But there is also the level of hosting, organizational measures in the library itself and the operation of the software, on which the FOLIO project has no influence.

During a security workshop at our library, we came across OWASP Application Security Verification Standard (ASVS) and OWASP Software Assurance Maturity Model (SAMM), which may be good frameworks (metric and guideance) for "technical and organisational measures" as mentioned in the ticket description. One approach could be to first break down the responsibilities, whereby the mentioned frameworks might help. In my opinion, this requirement also applies not only to the processing of personal data, but is also a prerequisite for any financial transaction. It would therefore be highly desirable to self-assess or have FOLIO assessed in a standardized manner according to these security aspects. 

Comment by Björn Muschall [ 03/Nov/21 ]

The OWASP Software Assurance Maturity Model (SAMM) also provides a comprehensive Toolbox spreadsheet for self-assessment. This might me a possible way to document the status of FOLIO's security activities, including calculation of maturity score for different areas (see below). As described above, some parts are probably the responsibility of the individual operating institution, others can be seen as the responsibility of the FOLIO project. Just as an idea how to process and document this requirement in a reasonably standardized way. I think that would suit most data protection officers in this regard.

Areas considered in this model:

Governance Strategy & Metrics
Governance Policy & Compliance
Governance Education & Guidance
Design Threat Assessment
Design Security Requirements
Design Secure Architecture
Implementation Secure Build
Implementation Secure Deployment
Implementation Defect Management
Verification Architecture Assessment
Verification Requirements Testing
Verification Security Testing
Operations Incident Management
Operations Environment Management
Operations Operational Management
Comment by Julian Ladisch [ 13/Apr/23 ]

TeleTrust Guideline "State of the Art": https://www.teletrust.de/en/publikationen/broschueren/state-of-the-art-in-it-security/

Generated at Fri Feb 09 00:27:32 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.