,
Ehsan Zabardast
, Jannik Fischbach ,
Tony Gorschek
, Daniel Mendez
,
Ehsan Zabardast
, Jannik Fischbach ,
Tony Gorschek
, Daniel Mendez
This website is a web version of the open data set for the study "Towards Goal-Centric Assessment of Requirements Engineering Methods for Privacy by Design". Open data set is available at Zenodo (DOI: 10.5281/zenodo.15760786) The website provides interactive functionality to explore the mapping of RE method characteristics (MCs) and method goals (MGs).
Method characteristic (MC) as a concrete and immediate outcome of method application and the quality of resulting RE artifacts to be achieved through the application of a method (e.g., consistency between requirements and system specifications).
RE method goal is a final purpose for which an outcome of a method is used and which drives the RE process.
For example, the method characteristic of consistency contributes to the goal of making decisions about compliance. In this study, we use the terms RE processes and RE methods as synonyms, as we also include ad hoc methods or approaches in the scope of our study.Privacy by design (PbD) is the specification and implementation of requirements and system architecture in response to GDPR norms. Our definition is focused on the core of PbD—the implementation of the norms of GDPR. PbD approach imposes special demands on the RE methods and artefacts in terms of capturing the intention of GDPR, formulated both in problem and solution-space-related demands, and consistently transmitting GDPR demands to the SDA phase of SDLC.
Requirements engineering (RE) for PbD as the requirements specification that captures both requirements and early architecture (constraints) in response to GDPR norms, facilitates demonstrable and verifiable compliance, and effectively communicates requirements and system constraints specified in GDPR for their implementation in the SDA phase. We use the term RE for PbD interchangeably with the term requirements and system specification for GDPR compliance.
The data presented is as follows:
|
MC1: Capturing legal domain knowledge is fundamental for capturing legal concepts, identifying privacy goals, and architecturally significant requirements, and essential to overcome the challenges of GDPR abstractness and the gap between engineering and legal perspectives. |
|
MC2: Traceability & Consistency of Specifications are important characteristics among others to address challenges of certification and compliance provability. |
|
MC3: Separation of Compliance & Non-Compliance Concerns can be seen as important because regulated data or system components can require specific handling (e.g., in case of regulatory updates). This SC is also essential to address challenges of conflicts with existing SE methods or outsourcing of software development. |
|
MC4: System Specification Transparency is important to address the need for involving or informing stakeholders and supporting stakeholders’ activities (e.g., risk management. |
|
MC5: System Specification Flexibility is required to react to changes both in regulations and software systems and maintain models developed for PbD implementation over time. Here, we consider that system specification is fundamental for the flexibility of software design and architecture. |
| ID | Comp. | Role | Exp. | GDPR Exp. | Rating | ||||
|---|---|---|---|---|---|---|---|---|---|
| MC1 | MC2 | MC3 | MC4 | MC5 | |||||
| I1 | C1 | Tech lead | 4 | 3 | 5 | 4 | 2 | 3 | 1 |
| I2 | C1 | Sales engineer | 4 | 6 | 4 | 1 | 5 | 2 | 3 |
| I3 | C1 | Stream lead | 28 | 6 | 3 | 4 | 1 | 2 | 5 |
| I4 | C1 | Data engineer | 3.5 | 3.5 | 1 | 2 | 5 | 3 | 4 |
| I5 | C2 | Web marketing spec. | 8 | 5 | 1 | 2 | 5 | 4 | 3 |
| I6 | C3 | Security manager | 34 | 7 | 1 | 2 | 5 | 4 | 3 |
| I7 | C4 | Data engineer | 4 | 2 | 2 | 1 | 5 | 4 | 3 |
| I8 | C5 | IT Compl.&Audit Head | 30 | 7 | 2 | 3 | 1 | 5 | 4 |
| I9 | C6 | Cloud Sec. Architect | 14 | 5 | 1 | 3 | 5 | 2 | 4 |
| I10 | C7 | Architect & Req-s Eng. | 7 | 6 | 1 | 2 | 5 | 3 | 4 |
| I11 | C8 | Project manager | 20 | 7 | 1 | 2 | 3 | 4 | 5 |
| I12 | C8 | Tech. project manager | 3 | 3 | 1 | 3 | 4 | 2 | 5 |
| I13 | C9 | Software developer | 12 | 7 | 1 | 4 | 5 | 3 | 2 |
| I14 | C10 | Software architect | 15 | 7 | 1 | 4 | 5 | 3 | 2 |
| I15 | C11 | Info. Security Expert | 3 | 8 | 1 | 4 | 5 | 3 | 2 |
| Median | 1 | 3 | 5 | 3 | 3 | ||||
| Sum | 26 | 41 | 61 | 47 | 50 | ||||
| ID | Method Character. | Goals | Questions | Metrics |
|---|---|---|---|---|
| I1 | MC1: Legal knowledge |
G1.1: Understand how data was classified
G1.2: Understand kinds of processing applicable to data
|
Q1.1: How do the legal and the technical experts interact? |
M1.1: Ability to classify data M1.2: Clarity of data classification M1.3: Automation of data classification |
| MC2: Traceability |
G1.3: Version control and ownership
|
Q1.2: How information about specifications persists? Q1.3: How does legal interpretation evolve? Q1.4: Is legal documentation available? |
M1.4: Clarity of ownership in documentation | |
| MC3: Concerns' separation |
G1.4: Prioritizing compliance
G1.5: Balancing need for agility and compliance
|
Q1.5: What is the need for processing the data? Q1.6: Can goals be achieved without processing data? Q1.7: Who is the stakeholder of data processing? Q1.8: How long data will be used? |
M1.5: Compliance of internal data users | |
| MC4: Spec. transparency |
G1.6: Clear mapping of GDPR sensitive data
G1.7: Identifying the level of data sensitivity
G1.8: Knowing data processing period
G1.9: Identifying purposes of processing
|
Q1.10: Is it clear how data was classified? Q1.11: Do stakeholders have access to the data classification? Q1.12: Do stakeholders understand the data classification? |
M1.6: Proportion of classified data M1.7: Classification understandability |
|
| MC5: Spec. flexibility |
G1.10: Identify components requiring flexibility
G1.11: Establish review process with GDPR experts
G1.12: Automation of compliance controls
G1.13: Communication
|
Q1.13: Is GDPR implementation clearly documented? Q1.14: Is there a change management process in place? Q1.15: How to hold on to GDPR compliance over time? Q1.16: Can non-data specialists understand GDPR compliance? |
M1.8: Portion of tagged system components | |
| I2 | MC1: Legal knowledge |
G2.1: Clear mapping of legal norms on IT system
|
NA | M2.1: How have we mapped all the requirements |
| MC2: Traceability |
G2.2: Updateability/modifiability of traceability
G2.3: Consistency
G2.4: Ease of implementation
|
NA | M2.2: Proportion of compliant data sources/systems | |
| MC3: Concerns' separation | NA | NA |
M2.3: Tracking progress of implementation M2.4: Progress of changes/updates |
|
| MC4: Spec. transparency |
G2.5: Documenting all the systems
G2.6: Documenting types of data processed
|
Q2.1: Is all the data and data processing documented? | M2.5: Percentage of data mapped | |
| MC5: Spec. flexibility | NA | NA |
M2.6: Time to implementing changes M2.7: Data sensitivity |
|
| I3 | MC1: Legal knowledge |
G3.1: Avoiding risks of non-compliance
|
NA | NA |
| MC2: Traceability |
G3.2: Optimal investment to manage non-compliance
|
Q3.1: Does your interpretation meet the financial risk? | M3.1: Time and resources for traceability implementation | |
| MC3: Concerns' separation | NA | NA | NA | |
| MC4: Spec. transparency |
G3.3: Passing audit
G3.4: Improving communication
|
Q3.2: Can you explain reasons for your design decisions? | M3.2: Explainability of design decisions | |
| MC5: Spec. flexibility | NA | NA | M3.3: Ratio of system changes to changes in regulations | |
| I4 | MC1: Legal knowledge |
G4.1: Understanding of design goals
G4.2: Understanding the required design flexibility
|
NA | NA |
| MC2: Traceability |
G4.3: Implementation and change history
|
Q4.1: How compliance was implemented? Q4.2: Why design was implemented in this way? |
M3.1: Time and resources for traceability implementation | |
| MC3: Concerns' separation |
G4.4: Merging compliance with business operations
|
Q4.3: How hard you put the bar of being compliant? | NA | |
| MC4: Spec. transparency |
G4.5: Privacy impact assessment
|
NA | NA | |
| MC5: Spec. flexibility |
G4.6: Effective implementation of changes
|
NA |
M4.2: Speed for implementing change M4.3: Lines of code requiring refactoring to implement change |
|
| I5 | MC1: Legal knowledge | NA | NA | NA |
| MC2: Traceability |
G5.1: Making sure that software works correctly
|
Q5.1: Are we collecting data before users give permission? Q5.2: Does Cookie banner satisfy GDPR requirements? Q5.3: Does customer requested to provide consent? |
NA | |
| MC3: Concerns' separation | NA | NA | NA | |
| MC4: Spec. transparency |
G5.2: Effective communication on system compliance
G5.3: Faster execution of business processes
|
NA | NA | |
| MC5: Spec. flexibility |
G5.4: Fast implementation of changes
G5.5: Adaptability
G5.6: Assuring web marketing needs
G5.7: Assuring personal data protection
|
Q5.4: Can we implement the changes in reasonable time? Q5.5: How can we collect data? Q5.6: What data can we collect? |
M5.1: Time M5.2: Difficulty of changes implementation |
|
| I6 | MC1: Legal knowledge |
G6.1: Balance business and compliance needs
G6.2: Finding consensus
G6.3: Bringing the required expertise together
G6.4: Performing gap analysis when required
G6.5: Team understands and can implement compliance
|
Q6.1: How to implement compliance? Q6.2: How to map to technology? Q6.3: What legal requirements are relevant? |
NA |
| MC2: Traceability |
G6.6: Executing governance
G6.7: Having proofs for inspections and when issues arise
|
Q6.4: Why do you do it? Q6.5: Have we done the best we were able to do? Q6.6: Have we missed something? Q6.7: Why did the gap in compliance emerge? Q6.8: Is there a risk, do we know it and can we manage it? |
M6.1: GDPR requirements - controls mapping M6.2: Number and severity of compliance gaps |
|
| MC3: Concerns' separation | NA | NA | NA | |
| MC4: Spec. transparency |
G6.8: Compliance/system is implemented as expected
|
Q6.9: Have we missed anything? | NA | |
| MC5: Spec. flexibility |
G6.9: Identification of components requiring updates
G6.10: Identifying what new vulnerabilities are relevant
|
Q6.10: Is it relevant for the company? Q6.11: Do we have blockers/technical debt? |
NA | |
| Other goals |
G6.11: Prevent personal data breaches
G6.12: Control IT infrastructure and its evolution
G6.13: Have a correct interpretation
|
NA | M6.3: Amount of incidents | |
| I7 | MC1: Legal knowledge |
G7.1: Implementation of system according to requirements
G7.2: Advising clients about GDPR compliance of solutions
|
Q7.1: Is solution or particular settings GDPR compliant? | M7.1: Compliance functionality availability |
| MC2: Traceability |
G7.3: Optimization of compliance implementation process
|
NA | NA | |
| MC3: Concerns' separation |
G7.4: Identifying components requiring GDPR compliance
G7.5: Not making things more complex
G7.6: Avoid additional expenditures and limitations
|
Q7.2: Should we implement GDPR compliance controls? Q7.3: Are we obliged to implement it? |
M7.2: Necessity to implement | |
| MC4: Spec. transparency |
G7.7: Everything should be clear to responsible roles
G7.8: Full understanding of requirements to each specific task
|
Q7.4: Can we achieve GDPR compliance for our system? Q7.5: Have we done everything correctly? |
M7.3: Clarity to responsible | |
| MC5: Spec. flexibility | NA | NA | NA | |
| Other goals |
G7.9: Processing as much data as possible
G7.10: Automation of external GDPR compliance checks
|
NA | NA | |
| I8 | MC1: Legal knowledge |
G8.1: Address GDPR as early as possible
G8.2: Making GDPR requirements clear to roles involved
G8.3: Higher quality of service
|
Q8.1: What kind of data is processed? Q8.2: Does the customer work in a regulated industry? |
NA |
| MC2: Traceability |
G8.4: Guarantee that specifications comply with GDPR
|
Q8.3: How easy is it to use traceability to implement change? Q8.4: How easy is it to trace requirements towards GDPR goal? Q8.5: How easy is it to track system to GDPR goals? |
M8.1: GDPR coverage | |
| MC3: Concerns' separation |
G8.5: Explicit identification of GDPR requirements
G8.6: Logic and functionality separation
G8.7: Audits facilitation
|
Q8.6: What mechanisms isolate compliance and business changes? |
M8.2: Number of compliance issues M8.3: Frequency of reviews M8.4: Degree of separation |
|
| MC4: Spec. transparency |
G8.8: Facilitating compliance reviews
G8.9: Improvement of communication
G8.10: Reducing risk of non-compliance
G8.11: Balancing different requirements and limitations
G8.12: Resolving conflicts between requirements
G8.13: Common understanding between stakeholders
|
Q8.7: How GDPR compliance is achieved? Q8.8: How easy is to review documentation for compliance? Q8.9: Is there a process in place for implementing changes? |
M8.5: Stakeholders' feedback M8.6: Ease of documentation review |
|
| MC5: Spec. flexibility |
G8.14: Modular design
G8.15: Adaptability of engineering processes
|
Q8.10: Are there mechanisms for targeted changes? Q8.11: How easy is to modify system spec. to reflect changes? |
NA | |
| Other goals |
G8.16: Manageability of non-compliance cases (breaches)
G8.17: Manageability of GDPR duties (e.g., consent)
|
Q8.12: Is there any process towards data subject requests? Q8.13: Do you have valid agreements with subcontractors? |
M8.7: Fulfillment time | |
| I9 | MC1: Legal knowledge |
G9.1: Awareness and responsibility
G9.2: Security of organization
|
Q9.1: How well are you aware about GDPR? Q9.2: What are the applicable GDPR demands? |
M9.1: Requirements readability M9.2: Number of compliant systems |
| MC2: Traceability |
G9.3: Control over compliance
G9.4: Visibility and identification of compliance gaps
G9.5: Clarity of compliance status
|
Q9.3: What controls are in place? Q9.4: Is there a req.-system mapping and how often is it updated? Q9.5: Who is responsible for compliance? |
M9.3: Number of gaps M9.4: Coverage of GDPR norms M9.5: Coverage of data processing systems |
|
| MC3: Concerns' separation | G9.6: Keep business running |
NA | NA | |
| MC4: Spec. transparency |
G9.7: Compliance simplification
G9.8: Avoid penalties
G9.9: Common understanding
G9.10: Efficient compliance
|
Q9.6: How communication is implemented? | M9.6: Number of communication channels | |
| MC5: Spec. flexibility | G9.11: Monitor gaps in compliance |
Q9.7: How the awareness about changes and their impact is implemented? |
M9.7: Time since update M9.8: Detection time |
|
| Other goals | G9.12: Compliance efficiency |
Q9.8: Do we need this data? | M9.9: Volume of personal data | |
| I10 | MC1: Legal knowledge |
G10.1: Clarity of GDPR requirements
G10.2: Concreteness of GDPR requirements
G10.3: Track changes
|
Q10.1: Does it work same in different situations? Q10.2: Is specification complete? Q10.3: Is anything missing? Q10.4: Are checks on system reaction to user input in place? |
M10.1: Agile process KPIs M10.2: Ability to visualize scenario M10.3: Sufficiency of information for developers |
| MC2: Traceability |
G10.4: Stay on track in case of changes
G10.5: Identifying where changes are required
G10.6: Compliance testability
G10.7: Ensure that processes support compliance implementation
|
Q10.5: Is compliance implementation testable? | M10.4: Passed tests | |
| MC3: Concerns' separation | G10.8: Clarity of what in specification is GDPR-relevant |
NA | NA | |
| MC4: Spec. transparency |
G10.9: Compliance testability
G10.10: Specification understandability
G10.11: Specification completeness
G10.12: Specification describes resulting software
|
NA | NA | |
| MC5: Spec. flexibility |
G10.13: Selecting the right abstractions
G10.14: Traceability to support evolution
G10.15: Breaking things down to smaller parts
G10.16: Separation of concerns
|
Q10.6: Can we break it down further? Q10.7: What can change in legal requirements? Q10.8: What is unlikely to change in legal requirements? |
M10.5: Module size M10.6: Modules complexity M10.7: Change rate M10.8: Number of scenarios and test cases |
|
| I11 | MC1: Legal knowledge |
G11.1: References to regulations
G11.2: Providing context for GDPR requirements in future
G11.3: Accessibility of legal knowledge
G11.4: Feeling confident about compliance
G11.5: Improving communication of requirements
G11.6: Spending the right effort
G11.7: Save time in next project
|
Q11.1: Are we implementing compliance right? Q11.2: Did we misunderstand it? Q11.3: What is good enough to implement compliance? Q11.4: Who can access data and how? Q11.5: What I need to do in the development process? Q11.6: Do we invest too much effort? |
M11.1: Number of data subject requests |
| MC2: Traceability |
G11.8: Develop what is required
G11.9: Not to develop what is not needed
G11.10: Not developing something wrong
G11.11: Not forgetting to develop something
G11.12: Ensuring software fulfills specification
G11.13: Maintain traceability
|
Q11.7: Where requirements come from? Q11.8: Is specification correct? Q11.9: Is system implemented as specified? Q11.10: Do test cases pass? Q11.11: Is customer happy with the implemented system? |
M11.2: Bugs' number M11.3: Incidents' numbers |
|
| MC3: Concerns' separation |
G11.14: Fulfilling certification and validation
G11.15: Ease of identifying what needs to be changed
G11.16: Providing proofs
G11.17: Visibility through “living compliance”
|
Q11.12: Do I comply with the stated requirements? Q11.13: Can I identify req-s, functions for implementation? Q11.14: Is documented compliance evaluation available? |
M11.4: Number of components requiring compliance M11.5: How many new components were added M11.6: Incidents' number M11.7: Time to report incidents |
|
| MC4: Spec. transparency |
G11.18: Ease to know what we are implementing
G11.19: Ease to know how we are implementing
G11.20: Choosing and discussing different solutions
G11.21: Ease of implementing updates
G11.22: Providing access to external auditor
|
Q11.15: Can I get an overview of relevant requirements? Q11.16: What is the origin of requirements? Q11.17: Do I know where requirements were implemented? |
||
| MC5: Spec. flexibility |
G11.23: Minimizing costs of changes and updates
G11.24: Good architecture of system
G11.25: Not to miss anything
G11.26: Identifying unnecessary work
G11.27: Facilitating recertification
|
Q11.18: What is the change required? Q11.19: Where change is required? Q11.20: Which code requires update? Q11.21: Which test cases require update? Q11.22: Which documentation requires update? |
M11.8: Compliance completeness M11.9: Number of components requiring compliance |
|
| Other goals | G11.28: Synthesizing best practices for compliance |
NA | NA | |
| I12 | MC1: Legal knowledge |
G12.1: Clarity to avoid misinterpretation
G12.2: Stakeholders understand what is required
|
Q12.1: Is specification understandable? Q12.2: Is specification easy to misinterprete? Q12.3: What should be done? |
M12.1: Specification clarity |
| MC2: Traceability |
G12.3: Facilitating auditors to trace from start to implementation
G12.4: Reaction to changes in regulations
|
Q12.4: Can I easily show or discuss compliance implementation? | NA | |
| MC3: Concerns' separation |
G12.5: Maintainability
G12.6: Scalability
|
Q12.5: In case of changes of software will compliance hold? | M12.2: Scalability | |
| MC4: Spec. transparency |
G12.7: Understandability of specification to experts and auditors
G12.8: Optimal effort
G12.9: Clear definition of personal data processed
G12.10: Clear specification of privacy policies
G12.11: Implementation of security controls to prevent breaches
|
Q12.6: Do we have enough security? Q12.7: Isn’t security effecting user friendliness too much? |
NA | |
| MC5: Spec. flexibility |
G12.12: Ease of compliance tracking
G12.13: Ease of identifying what requires changes
|
Q12.8: Can I find compliance implementation easily? Q12.9: How easy is to make changes without impacting other components? |
NA | |
| Other goals |
G12.14: Assuring data subject rights
G12.15: Transparency of data processing
|
NA | NA | |
| I13 | MC1: Legal knowledge |
G13.1: Not exposing to legal risk
G13.2: Achieving minimal legal requirements
|
Q13.1: What does the law require? Q13.2: How can system deliver what is required? Q13.3: Is the delivered functionality sufficient? |
M13.1: Test results by domain expert |
| MC2: Traceability |
G13.3: Ensuring compliance
G13.4: Documenting compliance
|
Q13.4: Is there a responsible person? Q13.5: Is there up to date documentation? |
NA | |
| MC3: Concerns' separation |
G13.5: Addressing legal concerns
G13.6: Satisfy data subjects' concerns
|
Q13.6: Are you sure you identified all the personal data? | M13.2: Response to data subject requests | |
| MC4: Spec. transparency |
G13.7: Translate between business, technical and legal
G13.8: Communicate in language that each party understands
|
Q13.7: What is required legally? Q13.8: What is implemented technically? Q13.9: Has compliance implementation been delivered? Q13.10: Is compliance understood? Q13.11: Is documentation available? Q13.12: Has everyone been informed? |
M13.3: Every stakeholder signed off | |
| MC5: Spec. flexibility | G13.9: Awareness about compliance when system is modified |
Q13.13: Are GDPR requir. incorporated into system requir. and test cases? | NA | |
| Other goals | G13.10: Addressing business needs |
NA | M13.4: Frequency of regulatory updates | |
| I14 | MC1: Legal knowledge |
G14.1: Involved roles understand the goals to be achieved
G14.2: Enable decisions on how to implement compliance
G14.3: Delegate teams autonomy to develop different solutions
|
Q14.1: Can teams provide different options to fulfill GDPR? Q14.2: Can we identify impacted processes and systems? |
M14.1: Team autonomy enablement M14.2: Autonomy in offering solutions |
| MC2: Traceability |
G14.4: Software maintainability
G14.5: Development team knows legal goals
G14.6: Teams can autonomously measure goals' achievement
|
Q14.3: What GDPR compl. goals do we want to achieve in our company? Q14.4: Do you know what are the strategies to achieve these goals? Q14.5: Whom to ask if you don’t know how to achieve these goals? |
M14.3: Frequency of requests about compliance M14.4: Number of options considered |
|
| MC3: Concerns' separation |
G14.7: Facilitate collaboration
G14.8: Breaking down GDPR into something specific
G14.9: Involvement of legal experts
|
Q14.6: Do we have an interpretation for our company? Q14.7: What does compliance mean for business and engineering? Q14.8: Do we have an interpretation for each business model? |
||
| MC4: Spec. transparency | G14.10: Shift left of compliance assessments |
Q14.9: Do we need to reverse engineer? Q14.10: Can we directly understand how compliance was implemented? |
M14.5: If every question can be answered | |
| MC5: Spec. flexibility |
G14.11: Plan required resources
G14.12: Capturing different types of changes
G14.13: Reacting to different types of changes
G14.14: Involving required stakeholders
G14.15: Employing the right tools/methods
G14.16: Identifying the impact on system
|
NA | NA | |
| I15 | MC1: Legal knowledge |
G15.1: Translate legal goals into business, technical requirements
G15.2: Good documentation available to roles involved
G15.3: Documenting decisions and solutions
G15.4: Help involved roles understand GDPR in their context
|
Q15.1: Do you have personal data in your system? Q15.2: For what purposes do you use personal data? |
M15.1: Responsibilities in place M15.2: Documentation availability M15.3: Sufficient knowledge and awareness M15.4: Use of compliance information |
| MC2: Traceability |
G15.5: Documentation
G15.6: Roles involved have knowledge and awareness
|
Q15.3: Is it related to GDPR compliance? Q15.4: Does it effect the processing of personal data? |
M15.5: Ability to identify GDPR concerns | |
| MC3: Concerns' separation |
G15.7: Understand gaps and risks
G15.8: Identify countermeasures to address high costs
|
Q15.5: Where do I have to be compliant? | ||
| MC4: Spec. transparency |
G15.9: Find GDPR norms addressed with specification
G15.10: Awareness about the implementation effort
|
Q15.6: How does it relate to my business? Q15.7: What is required to achieve compliance? |
M15.6: Effort required | |
| MC5: Spec. flexibility |
G15.11: Documentation
G15.12: Open architecture
|
Q15.8: Is particular service reusable? Q15.9: Can we implement changes easily? |
M15.7: Implementation rate M15.8: Reuse of compliance services across systems |
|
| Other goals |
G15.13: Compliance effectiveness
G15.14: Have an overview of compliance implementation
G15.15: Ongoing measurement of compliance effectiveness
G15.16: Addressing incomplete compliance and exceptions
|
Q15.10: Is compliance implemented effectively? Q15.11: What do I need to achieve compliance in my company? |
NA |
| Method goal (MG) |
|---|
| MG1: Facilitating GDPR compliance implementation throughout SDLC includes subgoals related to facilitating compliance in the design and architecture phase of SDLC (e.g., capacity to integrate GDPR controls), development phase (e.g., identifying relevant requirements for implementation), testing SDLC phase (e.g., testability of the implemented compliance) and also integration into SDLC models. |
| MG2: achieving understandability of GDPR is related to understandability of GDPR to the development team roles in the context of their tasks and common understanding between them, awareness about compliance-related aspects (e.g., relevant risks), concreteness and clarity of mapping of GDPR to a software system, sustainability of understanding (e.g., legal knowledge availability in the future), opportunities to synthesize best practices and assure understandability while using automation. |
| MG3: enabling decision-making included subgoals on making basic decisions possible, creating conditions for efficient compliance (e.g., prioritizing the implementation of obligatory controls), balancing compliance, technical, business, and other needs, planning and optimizing expenses, and effectively addressing and managing non-compliance (e.g., meeting financial risk). |
| MG4: Documenting the required information includes subgoals addressing documentation availability, versioning, and history, documentation content, and characteristics, and documentation of GDPR-to-system mapping. |
| MG5: Facilitating compliance governance subgoals are related to the establishment of processes basically supporting compliance (e.g., change management), and capacity to identify the required information. Subgoals for achieving validity focused on the compliance gaps and the overall compliance status, execution of other governance in connection to compliance (e.g., IT governance), and establishing compliance manageability. |
| MG6: Enabling response to changes subgoals focused on change identification (e.g., identifying what is likely to change), and facilitating the implementation of changes (e.g., implementation without impacting other components). |
| MG7: Verifiability&Validity of compliance implementation contained subgoals for achieving verifiability covering clarity and availability of information required for verification, and capacity to trace the required information. Subgoals for achieving validity focused on addressing validity from different stakeholder perspectives, clarity, and availability of the information for such perspectives, capacity to sustain validity, and identifying barriers to it. |
| MG8: Achieving effective communication on GDPR compliance implementation subgoals under MG consider the facilitation of cross-functional communication, achieving interaction between roles, translating between legal, technical, and business requirements, and communication in a common language. |
| MG9: facilitating GDPR compliance-related procedures focuses on facilitating procedures such as audits and compliance reviews. |
| MG10: addressing business-related concerns in PbD implementation is connected to facilitating the improvement of business processes, achievement, or maximization of business outcomes. |
| MG11: Facilitating risk and security management focuses on intersections between GDPR compliance and security, management of security, and privacy risks and controls. |
| Goals | Subgoals | Questions | Criteria/Metrics |
|---|---|---|---|
| MG1: Facilitating GDPR implementation throughout the SDLC | |||
| MG1.1: facilitating software design and architecture for GDPR compliance implementation | Q1.1.1: Does method support documenting GDPR compliance on software architecture level? | M1.1.1.1: documentation completeness | |
| Q1.1.2: Does method support architecture review engaging legal experts? | M1.1.2.1: reviews frequency | ||
| Q1.1.3: Does method support discerning GDPR compliance controls that need to be implemented? | M1.1.3.1: number of controls identified | ||
| Q1.1.4: Is it clear what is the priority for controls implementation? | M1.1.4.1: prioritization available | ||
| Q1.1.5: Does method facilitate compliance controls modularity? | M1.1.5.1: module size | ||
| M1.1.5.2: module complexity | |||
| Q1.1.6: Does method support isolation of compliance and business logic? | M1.1.6.1: separation degree | ||
| Q1.1.7: Does method facilitate GDPR controls reusability? | M1.1.7.1: component reuse | ||
| M1.1.7.2: implementation rate | |||
| Q1.1.8: Does method support "open" (flexible, adaptable, interoperable) architecture of controls implementation? | M1.1.8.1: ease of controls implementation | ||
| MG1.2: facilitating software development | Q1.2.1: Does method provide clarity that requirements originate from regulations? | M1.2.1.1: traceability coverage | |
| Q1.2.2: Does method facilitate specifications correctness? | M1.2.2.1: correctness | ||
| M1.2.2.2: number of compliance breaches | |||
| Q1.2.3: Does method provide an overview of relevant requirements? | M1.2.3.1: overview completeness | ||
| Q1.2.4: Is it possible to identify code that implemented compliance? | M1.2.4.1: traceability coverage | ||
| Q1.2.5: Does the method help avoid omitting any requirements? | M1.2.5.1: completeness | ||
| Q1.2.6: Does method help to understand priority in implementing compliance controls? | |||
| MG1.3: facilitating quality assurance | Q1.3.1: Does method facilitate compliance implementation testability? | M1.3.1.1: number of test cases | |
| Q1.3.2: Are test cases correct? | M1.3.2.1: proportion of correct test cases | ||
| Q1.3.3: Is compliance implemented correctly? | M1.3.3.1: number of passed test cases | ||
| MG1.4: facilitating compliance throughout engineering processes | Q1.4.1: Is it possible to integrate method into development model? | M1.4.1.1: number of conflicts with development model | |
| Q1.4.2: Is there a mechanism to assure compliance over time? | M1.4.2.1: usability | ||
| Q1.4.3: Can we directly understand how compliance was implemented (without reverse engineering)? | M1.4.3.1: proportion of compliance questions that can be answered | ||
| Q1.4.4: Is it clear what is the impact of GDPR compliance on software (engineering) processes? | M1.4.4.1: number of required changes | ||
| MG2 | |||
| MG2: Achieving understandability of GDPR in software engineering | MG2.1: clarity of GDPR to all the involved roles | Q2.1.1: Does method help to define the roles responsible for compliance implementation? | M2.1.1.1: roles established [Y/N] |
| Q2.1.2: Does method help to define responsibilities of each role? | M2.1.2.1: responsibilities established [Y/N] | ||
| Q2.1.3: Does method help to have a single source of information for all the roles to achieve common understanding? | M2.1.3.1: single source of information [Y/N] | ||
| Q2.1.4: Are specifications used by roles easy to misinterpret? | M2.1.4.1: correctness | ||
| Q2.1.5: Are specifications clear to each role in their context? | M2.1.5.1: number of ambiguities identified | ||
| M2.1.5.2: job relevance | |||
| M2.1.5.3: utility | |||
| M2.1.5.4: usefulness | |||
| M2.1.5.5: applicability | |||
| Q2.1.6: Can development team autonomously work on compliance using the method? | M2.1.4.1: number of external GDPR requests | ||
| M1.1.4.2: number of compliance breaches | |||
| MG2.2: assuring awareness about compliance aspects | Q2.2.1: Are the roles aware about the relevant risks? | M2.2.1.1: number of risks identified | |
| Q2.2.2: Are the roles aware of implementation effort? | M2.2.2.1: effort assessment is available [Y/N] | ||
| Q2.2.3: Does method facilitate clarity of the level of sufficient compliance in organization? | M2.2.3.1: roles feedback | ||
| Q2.2.4: Does method facilitate clarity of the GDPR compliance strategies in organization? | M2.2.4.1: roles feedback | ||
| MG2.3: concrete and clear GDPR-to-system mapping | Q2.3.1: Can method help to identify all relevant GDPR norms and concepts? | M2.3.1.1: completeness | |
| M2.3.1.2: coverage | |||
| Q2.3.2: Can method help to identify all relevant software components/data? | M2.3.2.1: completeness | ||
| M2.3.2.2: coverage | |||
| Q2.3.3: How reliable is the interpretation and mapping? | M2.3.3.1: accuracy | ||
| M2.3.3.2: correctness | |||
| MG2.4: sustaining understanding | Q2.4.1: Is GDPR interpretation available in clear form? | M2.4.1.1: usability | |
| Q2.4.2: Does interpretation work the same correct way in different projects? | M2.4.2.1: precision across projects | ||
| M2.4.2.2: recall across projects | |||
| M2.4.2.3: accuracy across projects | |||
| Q2.4.3: Are interpretation and required legal context information available in the future? | M2.4.3.1: completeness | ||
| Q2.4.4: Do understanding and awareness sustain in case of system or regulatory changes? | M2.4.4.1: traceability coverage of changes M2.4.4.2: updates number |
||
| MG2.5: synthesis of best practices | Q2.5.1: Can method facilitate synthesis of GDPR compliance best practices and reuse experience? | M2.5.1.1: documentation usability | |
| M2.5.1.2: documentation scalability | |||
| M2.5.1.3: documentation modularity | |||
| MG2.6: making automation understandable | Q2.6.1: Is it clear how automation works and is implemented? | M2.6.1.1: documentation availability | |
| M2.6.1.2: documentation usability | |||
| MG3 | |||
| MG3: Enabling decisionmaking on GDPR compliance | MG3.1: enabling basic decisions | Q3.1.1: Does method make information required for decisionmaking available? | M3.1.1.1: documentation completeness |
| Q3.1.2: Does method facilitate identification of different compliance solutions to consider? | M3.1.2.1: number of compliance solutions | ||
| Q3.1.3: Can method help identify impact of GDPR compliance on a system? | M3.1.3.1: number of components requiring changes | ||
| Q3.1.4: Can we make decisions about compliance with the help of the method? | M3.1.4.1: number of decisions | ||
| MG3.2: identifying optimal and efficient compliance | Q3.2.1: Can method facilitate identification of implementation priority? | M3.2.1.1: proportion of obligatory requirements identified | |
| Q3.2.2: Can method clarify if business goals can be achieved without processing personal data? | M3.2.2.1: proportion of data requiring compliance | ||
| Q3.2.3: Can method facilitate compliance minimization? | M3.2.3.1: proportion of requirements that can be minimized | ||
| Q3.2.4: Can method facilitate identification of risk of being fined? | Q3.2.4.1: number of risks identified | ||
| Q3.2.5: Does method support identification of the degree of compliance we would like to implement? | Q3.2.5.1: requirements coverage | ||
| MG3.3: balancing technical, compliance, business and other needs | Q3.3.1: Can method help identify different types of concerns impacted by compliance? | Q3.3.1.1: number of types of concerns identified | |
| Q3.3.2: Can method help identify impacted business concerns? | M3.3.2.1: number of impacted business concerns identified | ||
| Q3.3.3: Can method help identify impacted technical concerns? | M3.3.3.1: number of impacted technical components | ||
| Q3.3.4: Can method help identifying and resolving conflicts between different concerns? | M3.3.4.1: conflicts identified | ||
| M3.3.4.2: conflicts resolved | |||
| M3.3.4.3: specifications' consistency | |||
| MG3.4: plan and optimize expenses | Q3.4.1: What are the changes in system/processes required to implement compliance? | M3.4.1.1: number of changes identified | |
| Q3.4.2: Can method help to identify the cost of required changes? | M3.4.2.1: cost estimation available [Y/N] | ||
| MG3.5: effectively address and manage non-compliance | Q3.5.1: Can method help identify if compliance implementation meets the financial risk? | M3.5.1.1: costs estimation available [Y] | |
| Q3.5.2: Can method help to identify availability of resources to manage non-compliance? | M3.5.2.1: resource availability estimation [Y/N] | ||
| MG4 | |||
| MG4: Documenting the required information | MG4.1: availability of required documentation | Q4.1.1: Is legal documentation available? | M4.1.1.1: documentation completeness |
| Q4.1.2: Is documentation relevant for the roles involved? | M4.1.2.1: use of compliance information | ||
| M4.1.2.2: documentation usability | |||
| Q4.1.3: Does documentation facilitate roles understanding and awareness? | M4.1.3.1: roles feedback | ||
| Q4.1.4: Is ownership clear in documentation? | M4.1.4.1: number of owners identified | ||
| MG4.2: having documentation versioning and history | Q4.2.1: Are versions of legal interpretation available? | M4.2.1.1: number of interpretation versions | |
| Q4.2.2: Does method allow to track how legal interpretation evolved? | M4.2.2.1: number of interpretation versions | ||
| MG4.3: assuring documentation has required content | Q4.3.1: Does method allow to document data classification? | M4.3.1.1: proportion of classified data | |
| Q4.3.2: Does method allow documenting data processing activities and purposes classification? | M4.3.2.1: proportion of processing and purposes mapped | ||
| Q4.3.3: Does method allow documenting period of data processing? | M4.3.3.1: proportion of processing period documented | ||
| Q4.3.4: Does method allow documenting who can access data and how? | M4.3.4.1: proportion of documented entities having data access | ||
| Q4.3.5: Does method allow documenting sources of requirements? | M4.3.5.1: proportion of sources documented | ||
| Q4.3.6: Does method allow documenting decisions made and solutions? | M4.3.6.1: number of decisions and solutions documented | ||
| MG4.4: assuring documentation meets characteristics | Q4.4.1: Does method support keeping documentation up to date? | M4.4.1.1: update frequency | |
| Q4.4.2: Does method support documentation correctness? | Q4.4.2.1: number of GDPR breaches | ||
| Q4.4.3: Is it possible to find GDPR norms addressed with specification using the method? | M4.4.3.1: proportion of norms identified | ||
| Q4.4.4: Is it possible to get an overview of how compliance was implemented? | M4.4.4.1: proportion of controls documented | ||
| Q4.4.5: Is documentation understandable? | M4.4.5.1: roles feedback | ||
| Q4.4.6: Is it possible to identify a design rationale? | M4.4.6.1: roles feedback | ||
| Q4.4.7: Is it possible to identify the required effort? | M4.4.7.1: roles feedback | ||
| Q4.4.8: Is it possible to isolate components requiring compliance and business changes? | M4.4.8.1: degree of separation | ||
| Q4.4.9: Is it possible to easily identify responsible persons and responsibilities? | M4.4.9.1: roles feedback | ||
| MG4.5: documenting GDPR-to-system mapping | Q4.5.1: Is requirements-to-system traceability documented? | M4.5.1.1: proportion of requirements-to-system traces documented | |
| Q4.5.2: Is GDPR-to-system traceability documented? | M4.5.2.1: proportion of GDPR-to-system traces documented | ||
| Q4.5.3: Is GDPR-to-requirements traceability documented? | M4.5.3.1: proportion fo GDPR-to-system traces documented | ||
| Q4.5.4: Are all relevant requirements mapped to system components? | M4.5.4.1: completeness | ||
| Q4.5.5: Is it documented how mapping was conducted? | M4.5.5.1: procedure description availability [Y/N] | ||
| Q4.5.6: Is documentation usable for compliance verification? | M4.5.6.1: documentation usability | ||
| M4.5.6.2: roles feedback | |||
| MG5 | |||
| MG5: Facilitating GDPR compliance governance | MG5.1: achieving minimal process maturity for governance | Q5.1.1: Does method support documentation process? | M5.1.1.1: documentation completeness |
| Q5.1.2: Does method support a change management process? | M5.1.2.1: number of changes covered | ||
| Q5.1.3: Does method support a verification/validation process? | M5.1.3.1: number of verification/validation procedures | ||
| Q5.1.4: Does method support finding compliance implementation easily? | M5.1.4.1: usability | ||
| Q5.1.5: Does method support documenting compliance evaluation results? | M5.1.5.1: number of evaluation procedures documented | ||
| MG5.2: identification of compliance gaps and status | Q5.2.1: Is GDPR-reqs-system traceability available? | M5.2.1.1: coverage of GDPR norms | |
| Q5.2.2: Does method support easy documentation of changes? | M5.2.2.1: time since last change documented | ||
| M5.2.2.2: number of undocumented changes since last update | |||
| Q5.2.3: Is it possible to identify compliance gaps? | M5.2.3.1: usability | ||
| Q5.2.4: How fast can we identify compliance gaps? | M5.2.4.1: detection time | ||
| Q5.2.5: Is it possible to identify overall compliance status? | M5.2.5.1: time for status identification | ||
| Q5.2.6: Is it possible to monitor compliance status? | M5.2.6.1: number of compliance breaches identified | ||
| MG5.3: facilitating other governance tasks | Q5.3.1: Is it possible to identify compliance rationale? | M5.3.1.1: roles feedback | |
| Q5.3.2: Does method provide information if compliance implemented effectively and efficiently? | M5.3.2.1: number and severity of compliance gaps | ||
| M5.3.2.2: cost of implementing compliance | |||
| Q5.3.3: Is there visibility into data access? | M5.3.3.1: proportion of entities and processing purposes covered | ||
| Q5.3.4: Does method facilitate IT infrastructure governance and its evolution along with compliance? | M5.3.4.1: roles feedback | ||
| MG5.4: achieving manageability of compliance | Q5.4.1: Is it possible to manage/control compliance? | M5.4.1.1: roles feedback | |
| Q5.4.2: Is it possible to manage/control non-compliance (breaches)? | M5.4.2.1: proportion of breaches successfully addressed | ||
| Q5.4.3: Is it possible to manage/control all GDPR duties (e.g., consent)? | M5.4.3.1: proportion of duty-related requests addressed | ||
| Q5.4.4: Does method provide an overview of resources required for compliance? Q5.4.5: Is it possible to identify root causes of gaps/non-compliance? Q5.4.6: Is there a real-time visibility and manageability of compliance (living compliance)? |
M5.4.4.1: resource overview availability [Y/N] M5.4.5.1: number of root causes identified M5.4.6.1: time to report incidents |
||
| MG6 | |||
| MG6: Enabling response to changes | MG6.1: identification of changes | Q6.1.1: What is likely and unlikely change in regulations? | M6.1.1.1: change rate |
| Q6.1.2: Does method help to identify relevance of changes? | M6.1.2.1: number of changes successfully addressed | ||
| Q6.1.3: Can method help identify req-s, functions requiring changes? | M6.1.3.1: number of changes successfully addressed | ||
| Q6.1.4: Can I find compliance implementation easily? | M6.1.4.1: number of controls identified | ||
| M6.1.4.2: usability | |||
| MG6.2: facilitation of changes implementation | Q6.2.1: Can we implement changes in reasonable time? | M6.2.1.1: time to implement changes | |
| Q6.2.2: Does method make it easy to make changes without impacting other components? | M6.2.2.1: difficulty of changes implementation | ||
| MG7 | |||
| MG7: Achieving verifiability & validity of compliance | MG7.1: facilitate compliance verifiability | Q7.1.1: Is it clear how compliance was achieved? | M7.1.1.1: roles feedback |
| Q7.1.2: Is it clear what are the legal norms/goals implemented? | M7.1.2.1: GDPR requirements–controls mapping completeness | ||
| Q7.1.3: Is it clear what are the GDPR-relevant requirements and system components? | M7.1.3.1: GDPR requirements–controls mapping completeness | ||
| Q7.1.4: Have we missed any information required for verification? | M7.1.4.1: completeness | ||
| Q7.1.5: Is it possible to identify the degree of compliance? | M7.1.5.1: GDPR coverage | ||
| Q7.1.6: How easy is it to trace requirements and system components towards GDPR norms? | M7.1.6.1: usability | ||
| MG7.2: facilitate compliance validity | Q7.2.1: Is it clear what is implemented towards compliance? | M7.2.1.1: controls coverage | |
| Q7.2.2: Is it clear what is required by law (validity criteria)? | M7.2.2.1: norms coverage | ||
| Q7.2.3: Are demands of legal stakeholders addressed in a valid way? | M7.2.3.1: number and severity of compliance breaches | ||
| Q7.2.4: Are demands of data subjects addressed in a valid way? | M7.2.4.1: proportion of successful response to data subject requests | ||
| Q7.2.5: Does specification facilitate informing users and collecting consent? | M7.2.5.1: proportion of successful response to data subject requests | ||
| Q7.2.6: Are demands of other stakeholders addressed in a valid way? | M7.2.6.1: Stakeholders' feedback | ||
| Q7.2.7: Is it possible to sustain compliance validity? | M7.2.7.1: number of invalidity of compliance throughout time | ||
| Q7.2.8: Can we identify barriers to valid compliance implementation? | M7.2.8.1: number of barriers identified | ||
| MG8 | |||
| MG8: Effective communication and collaboration on GDPR compliance | MG8.1: facilitating cross-functional communication | Q8.1.1: Can non-technical specialists communicate about technical implementation of GDPR? | M8.1.1.1: explainability of design decisions |
| Q8.1.2: Can technical specialists communicate about what is legally required? | M8.1.2.1: explainability of legal documentation | ||
| Q8.1.3: Can roles communicate about GDPR-to-system mapping? | M8.1.3.1: use of GDPR-to-system mapping | ||
| Q8.1.4: How easy is it to review documentation for compliance? | M8.1.4.1: usability | ||
| MG8.2: achieving interaction and communication between the roles | Q8.2.1: Can roles jointly interpret GDPR? | M8.2.1.1: number of GDPR-to-system traces identified jointly | |
| Q8.2.2: Are all the roles involved and informed when required? | M8.2.2.1: number of notifications | ||
| MG8.3: translating between legal, technical and business requirements | Q8.3.1: Does communication include all the concerns? | M8.3.1.1: every stakeholder signed off | |
| Q8.3.2: Can different concerns be addressed simultaneously? | M8.3.2.1: traceability between all the concerns involved | ||
| MG8.4: communication in common language | Q8.4.1: Is there one single interpretation of GDPR for all roles? | M8.4.1.1: availability of compliance documentation | |
| Q8.4.2: Is interpretation useful for every role involved? | M8.4.2.1: usability of compliance documentation | ||
| MG9 | |||
| MG9: Facilitating GDPR compliance-related procedures | Q9.1.1: Does method facilitate audits and compliance assessments? | M9.1.1.1: Stakeholders' feedback | |
| M9.1.1.2: degree of separation | |||
| Q9.1.2: Does method facilitate certification? | M9.1.2.1: Stakeholders' feedback | ||
| Q9.1.3: Does method facilitate complete traceability? | M9.1.3.1: traceability completeness | ||
| Q9.1.4: Is it clear how GDPR compliance is achieved? | M9.1.4.1: documentation completeness | ||
| Q9.1.5: How easy is it to review documentation for compliance? | M9.1.5.1: ease of documentation review | ||
| MG10 | |||
| MMG10: Addressing business concerns in GDPR compliance | NA | Q10.1.1: Does method contribute to better execution of business processes? | M10.1.1.1: impact on processes and effort |
| Q10.1.2: Can we facilitate business needs of different functions? | M10.1.2.1: number of business needs documented | ||
| Q10.1.3: Can we identify what data can we collect? | M10.1.3.1: availability of allowed data to stakeholders | ||
| Q10.1.4: Can we assure that we process as much data as possible? | M10.1.4.1: number of restrictions on personal data processing | ||
| MG11 | |||
| MMG11: Facilitate security & risk management | Q11.1.1: Does method allow to identify the implications of GDPR compliance implementation on security? | M11.1.1.1: completeness of information about GDPR controls | |
| Q11.1.2: Does method support mapping of security and privacy requirements and controls? | M11.1.2.1: number of security and privacy controls mapped | ||
| Q11.1.3: Does method support mapping of risks and privacy requirements and controls? | M11.1.3.1: number of risk and privacy controls mapped | ||
| Q11.1.4: Does method support implementation of privacy & security controls? | M11.1.4.1: number of privacy & security controls implemented | ||
| ID | Comp. | Role | Exp. | GDPR Exp. | Subg. (of 32) | Quest. (of 148) | Metric (of 172) | |||
|---|---|---|---|---|---|---|---|---|---|---|
| U | F | U | F | U | F | |||||
| I5 | C2 | Web marketing spec. | 8 | 5 | 32 | 32 | 146 | 137 | 167 | 158 |
| I13 | C9 | Software developer | 12 | 7 | 32 | 27 | 146 | 132 | 170 | 152 |
| I16 | C12 | Data Protection Officer | 7 | 7 | 32 | 32 | 147 | 141 | 152 | 142 |
| I17 | C13 | Data Protection Advisor | 4 | 4 | 31 | 16 | 137 | 98 | 158 | 75 |
| I18 | C14 | Cloud Sec. Architect | 2.5 | 5 | 31 | 30 | 140 | 131 | 150 | 141 |
| I19 | C15 | Software Developer | 29 | 28 | 141 | 135 | 159 | 152 | ||