Introduction
When we discuss policy creation elements in this context, we are talking about starting with business requirements (a task or series of tasks needed to serve a goal) and functionality goals. Once defined for goals and basic functions, we add requirements driven by applicable law. We then fit and bend our requirements to view the policies we must create through a lens of functionality (i.e., each action taken or demanded may be viewed as a requirement specification that must be included in a system). That system may be an enterprise, a subunit, end-to-end processing cycle, application, an element of functionality, a person-managed governance activity, among others. There is no exclusive list of what constitutes a system.
This is not a discussion chief privacy officers (CPOs; or whomever is leading the privacy function) will have with every privacy engineer; however, every CPO must consider the output of his or her labor in terms of the concrete and measurable requirements and the outcomes discussed here.
Elements Of Privacy Engineering Development
Enterprise goals
They must be reflected and aligned with privacy engineering solutions, including their privacy policies, standards, and guidelines. To make this happen, a privacy development team1 must first understand the goals and objectives of the enterprise in which the solution will operate. In this context, “enterprise” includes organizations large and small that manage or otherwise process data. This definition would, of course, include government entities that may be governed by specific or additional rules and regulations and the organizing principles will still apply.
User/individual goals
These must be incorporated to develop effective and flexible privacy policies that will be accepted by the end user and individuals. The team members must understand the goals and objectives (and privacy sensibilities) of the end users and individuals who will participate in the system or become the data subjects for PI managed by the system.
Privacy policy
The policy plays a key role in guiding how privacy engineering is applied.
Privacy requirements
Requirement gathering is critical for effective policy creation and solution development. This is when we describes the application of use cases for requirement collection and introduces a unique use-case metadata model.
Privacy procedures and processes
These are the overall privacy activities (procedures) and their human or automated tasks (processes). Mandated standards and recommended guidelines factor into the creation of procedures and processes. It is procedures, processes, standards, and guidelines that translate “policy” into reality.
Privacy mechanisms
These are the automated solutions built with software and hardware to enforce privacy policies. This including a privacy engineering component and how it can fit within an application system environment.
Privacy awareness and readiness preparation
As part of developing a privacy engineered solution, the team will engage with various stakeholders so they are aware of what the Privacy Policy is and what it does. The privacy team works together with these stakeholders to address how the privacy-engineered solution could affect their roles and responsibilities.
Quality assurance
This is required to ensure that the privacy engineering solution functions properly, as well as satisfies enterprise goals, user goals, and accepted privacy standards within the context they are to operate.
Feedback loop
This will ensure that the privacy engineering solution is improved continuously as it will periodically quality assess or audit the solution and build in the ability to do so as a technical and procedural requirement.
Conslusion
From the article, Whether you are a privacy professional or an engineer without
a privacy background, you should have an understanding of how privacy is engineered
into systems.
Ref no : DTC-WPUB-000094
Ref : The Privacy Engineer's Manifesto: Getting from Policy to Code to QA to Value
About Author
Comments
Post a Comment