# Security and Privacy Requirements Security and privacy requirements are Standing Requirements that carry approved product obligations across delivery increments. This paper explains how people assuming Product Owner or Product Manager responsibilities combine specialist advice with product context, make the resulting requirements clear enough for human and AI contributors to use, and maintain them as policies, risks, and related requirements change. The intended result is a maintained basis for deriving compliant functional specifications and verifying the software delivered from them. Requirements reuse provides the research foundation for this method. Christian and Mead identify security requirements that are too vague to guide delivery or so specific that they prescribe particular mechanisms. Their report, Security Requirements Reusability and the SQUARE Methodology, examines reuse through generalized requirements and a shared understanding of security concepts. It proposes R-SQUARE, a reuse-oriented variant of the Security Quality Requirements Engineering methodology.[^citation-01] In AI-assisted delivery, that requirement for clarity extends to the applicability, assumptions, exceptions, and relationships that subsequent work needs to interpret correctly. Specification-First Delivery makes their maintenance and coordination part of the Knowledge System: an interpretation must remain usable when another increment, person, or AI session takes it up. Security requirements express the protection a product must provide for its information, assets, and services. Privacy requirements address information processing and its effects on people, including effects that can arise while the system operates as intended. This broader view of privacy risk is described in the Privacy Framework from the National Institute of Standards and Technology (NIST).[^citation-02] Both concerns draw on applicable law, regulatory guidance, contracts, organizational policy where present, and professional risk judgment. [Standing Product Requirements and Constraints](/en-us/hub/standing-product-requirements-and-constraints) defines how those judgments become durable product obligations; this paper specializes their content, use, and review. Throughout this paper, the Cookies example follows a web application's handling of cookie consent. The example illustrates how a high-level privacy obligation becomes a recurring product requirement. A web application may use cookies, small values retained by the user's browser, to remember preferences between visits. The team must determine which uses require consent and what the application should do when a person grants, declines, or withdraws it. Implementing those decisions involves product behavior, specialist judgment, a technical control, and evidence that the user's choice takes effect. The example assumes that a qualified privacy decision owner has determined that a defined group of optional preference cookies requires consent, while authentication cookies and consent records have their own approved treatment. The team uses a shared cookie-management component to apply the decisions as new features are added. ## 1. Specialist Authority and Product Accountability The person assuming the Product Owner or Product Manager role is ultimately accountable for product compliance within the delivery model. Larger organizations commonly assign these responsibilities to dedicated roles; in a smaller team, an engineer or founder may also assume them. The responsibilities described here can therefore be combined in one person, with decision authority and any required independent review kept explicit. Whoever assumes the product role must understand the applicable obligations, supply the product context needed to interpret them, obtain appropriate professional advice, and ensure that the agreed requirements reach specifications and acceptance decisions. Product context includes what the product does, whose data it handles, why it processes that data, and which services receive it. Legal or compliance specialists may understand the obligation without knowing these facts, so product accountability includes making them available and correcting them when the product changes. Security and privacy specialists assess threats, privacy impacts, and the adequacy of proposed controls. Legal and compliance specialists, where available, help determine applicable obligations and their interpretation; a team may obtain the required expertise externally. The organization assigns authority for approving professional judgments, resolving disputed interpretations, and accepting residual risk or an allowed exception. This allocation preserves specialist decision rights while the Product Owner or Product Manager remains responsible for applying the judgments to the product. An allocation of responsibility must also explain how decisions are communicated and reviewed. The NIST Cybersecurity Framework 2.0 provides a relevant governance reference: it organizes cybersecurity outcomes into functions, with GOVERN addressing risk strategy, policy, roles, responsibilities, and oversight.[^citation-03] The practical preparation task here is to identify the source and decision owner for each material obligation, record the scope of their authority, and establish how unresolved questions reach them. These arrangements make professional advice available to subsequent delivery work. Product accountability operates alongside the responsibilities established by applicable law. For example, the European Union's General Data Protection Regulation (GDPR) assigns duties to the controller. Guidance from the European Data Protection Board (EDPB) explains the controller's responsibility for effective data-protection measures and safeguards.[^citation-04] A product team working under that regime must identify the relevant controller and its duties as part of its context. Other legal regimes may allocate responsibilities differently. The framework's Product Owner or Product Manager role establishes delivery accountability; the applicable law determines the legal responsibilities that the product must address. Specialist advice becomes usable product knowledge when it is examined against the intended behavior and actual data flows. The Product Owner or Product Manager brings that advice and product context into [Structured Discussion](/en-us/hub/requirements-increments-and-structured-discussion), so the relevant participants can resolve applicability, assumptions, exceptions, and competing obligations. AI can organize sources and expose questions during that discussion. Qualified people review the professional conclusions and confirm decisions within their authority. Treating an unreviewed AI interpretation as settled can carry the same error into specifications, implementation, and tests. When performing business analysis, architecture, engineering, or quality work, contributors use these approved judgments to define behavior, design, implementation, and evidence. In those activities they are downstream users of the judgments, including when the same person also assumes product-management responsibilities. They contribute facts that may require renewed specialist assessment and need to understand the policies relevant to their work, even when existing controls carry out the routine enforcement. In the Cookies example, product management explains which preferences the feature remembers and why. Privacy and, where needed, legal or compliance expertise informs the consent and retention decisions. Security expertise informs access and exposure risks. Product management then ensures that the approved cookie behavior is reflected in the functional specification and its acceptance conditions. ## 2. Formation and Reuse of Product-Specific Requirements ### 2.1. Organizational Context and Product Interpretation The product team establishes authoritative product-specific requirements from the sources relevant to its obligations. Where an organization maintains policies, standards, control catalogs, or approved patterns, its organizational context layer supplies reusable inputs. The team selects the relevant sources and customizes their application to the product. Where that layer is absent, the Product Owner or Product Manager assembles the applicable sources and specialist judgments directly. [The Shared Knowledge System](/en-us/hub/shared-knowledge-system) explains how broader knowledge and product-specific interpretation connect; a separately maintained organizational layer is one available source of that knowledge. The work of interpretation connects an obligation to the product decisions needed to satisfy it. A privacy principle concerning data minimization, for example, still requires a judgment about which data the product needs for its stated purpose. This movement from principle to design is examined in ENISA's Privacy and Data Protection by Design report, which relates legal principles to design strategies and technical measures.[^citation-05] The product record preserves the approved interpretation, its source and version where available, its decision owner, and the rationale that explains its application. An organization might expose its policy repository through the Model Context Protocol (MCP), a way for AI tools to access connected resources. In that arrangement, the service provides access to the maintained source; product-specific knowledge records how it applies to the software. Customization makes those implications directly usable, and the team assigns source checks and review to keep the interpretation current. Governing Instructions identify the knowledge contributors must consult for relevant work. In the Cookies example, a change to consent or cookie behavior brings the approved requirements and implementation guidance into scope. A Skill can provide the procedure for applying them. Where a tool loads Skills selectively, mandatory reading and operating rules belong in the applicable Governing Instructions. The team checks that the AI can retrieve the sources through its actual access path. The same selection of context serves people. A Product Manager needs the obligations and their product consequences; an engineer additionally needs the approved design and current implementation. Progressive Context Loading, described in The Shared Knowledge System, organizes AI access from broader context toward the knowledge needed for the current task. Humans likewise select knowledge according to their professional responsibility and the work at hand. ### 2.2. Clarity and Reuse Conditions For a requirement to be reused, the next participant must understand both its meaning and its applicability. R-SQUARE addresses the first part through common security concepts and well-specified, generalized requirements that can be used where systems face similar threats.[^citation-01] A product-specific Standing Requirement also needs to identify the circumstances in which that reasoning holds. In the Cookies example, those circumstances include the classified preference cookies, their purpose, and the conditions under which consent is required. The following information makes the approved judgment available to subsequent human and AI contributors. It elaborates the reference structure in [Standing Product Requirements and Constraints](/en-us/hub/standing-product-requirements-and-constraints) and can be recorded together or reached through maintained links. 1. **Meaning and applicability** Identify the data, actors, purposes, capabilities, and operating conditions covered by the requirement. 2. **Required outcome** State the obligation or restriction clearly enough for a qualified participant to determine what evidence would establish conformance. 3. **Assumptions and exceptions** Record the facts supporting applicability, any approved exceptions, and their expiry or review conditions. 4. **Authority and provenance** Identify who confirmed the interpretation and where its source and decision record can be examined. 5. **Related requirements** Identify other obligations affecting the same behavior and retain the resolution of their material interactions. 6. **Verification and review** State the expected evidence and the changes or scheduled reviews that require renewed judgment. A usable cookie requirement specifies which preference cookies may be set or read, for what purpose, under which consent conditions, and what must happen when those conditions cease to hold. The shared cookie API implements part of that decision. Keeping the obligation explicit allows the team to assess a replacement component against the same required outcome. ### 2.3. Formation Dependencies Product Intent supplies the starting purpose. Other Standing Requirements can be formed as the product's needs become clear and can inform one another when relevant knowledge already exists. Applicability determines what must be established before a particular decision. Preparation therefore follows material dependencies, with applicable obligations remaining binding while their product-specific records are developed. Product management and the relevant specialists identify gaps and the work that depends on resolving them. Existing reliability, data, architecture, or integration knowledge can expose a missing privacy assumption; a new privacy requirement can reveal a corresponding gap in those areas. Each material gap needs an owner and a point before which it must be resolved, using the method in [Knowledge System Readiness](/en-us/hub/knowledge-system-readiness-for-specification-first-delivery). For the Cookies example, the team records the requirement that the classified preference cookies may be set and used only for their stated purpose while the required consent is valid. It specifies the cessation and removal outcome when consent is withdrawn. The related decision record identifies the data covered, the approved interpretation, and the separate treatment of consent evidence, giving later increments a requirement they can apply and examine. ## 3. Threats, Privacy Impacts, and Assumptions A requirement needs enough analytical context for a qualified participant to understand why it exists and recognize a material change. Security analysis examines threats to protected assets and services. Privacy analysis examines potential effects on individuals across collection, use, disclosure, retention, and disposal of data. These assessments depend on knowing where data goes and what can happen to it. One method for privacy analysis is LINDDUN, which relates categories of privacy threats to a system's data-flow model and supports the elicitation of requirements.[^citation-06] For the wider assessment of risk, NIST's Guide for Conducting Risk Assessments organizes the examination of threats, vulnerabilities, likelihood, and impact as inputs to decisions.[^citation-07] Specialists select suitable methods and retain the conclusions that explain the product's requirements, together with the conditions on which those conclusions depend. The analysis record should make those conditions inspectable. The fields below provide a reference structure for the decision provenance associated with a security or privacy Standing Requirement. 1. **Protected interests** Identify the information, assets, services, or interests of individuals affected by the requirement. 2. **Threat or privacy impact** Describe the event, processing activity, or misuse that could produce an adverse outcome, and who or what would be affected. 3. **Relevant context** Record the data categories, purposes, recipients, access relationships, retention, and operating locations that affect the judgment. 4. **Supporting assumptions** State the facts on which the assessment depends and provide a route to evidence where material. 5. **Review conditions** Identify the changes or findings that require the decision owner to reassess the requirement or its control. In the Cookies example, security analysis considers unauthorized access to preference values. Privacy analysis also examines retention beyond the approved purpose and use after withdrawal. The initial judgment assumes that the preference cookies serve the stated convenience function, are used only by the intended product components, and are handled through the approved cookie-management path. An increment that shares those preferences with an analytics provider changes the purpose or recipient assumptions. The participant discovering the change records the proposed data flow and routes it to product management and the relevant specialists before dependent specifications are approved. They assess the new circumstances against the existing requirements and determine what additional or revised obligations are needed. ## 4. Control Decisions and Interactions among Standing Requirements ### 4.1. Control Intent and Residual Risk A control is a measure selected to achieve a security or privacy outcome. Its decision record explains the intended effect, selection rationale, applicability, expected evidence, and limitations. Residual risk is the assessed risk remaining after the selected measures are taken into account. The organization assigns authority to accept that risk within applicable obligations and exception rules. Control selection begins by deciding what protection the product needs to achieve. Privacy design strategies offer a useful vocabulary for that decision before a specific mechanism is chosen. Hoepman identifies eight strategies spanning data handling and organizational process: minimize, hide, separate, aggregate, inform, control, enforce, and demonstrate. These strategies connect early privacy decisions with design patterns and technologies.[^citation-08] For the Cookies example, reducing the preferences retained and enabling a user to exercise a choice establish different control purposes, each of which needs an adequate implementation. The Standing Requirement expresses the obligation and its verifiable result. The associated decision record explains why the selected measures are adequate, while architecture knowledge, Governing Instructions, and technical specifications carry the concrete design and operating rules. [Standing Requirement Specifications and Decision Records](/en-us/hub/standing-product-requirements-and-constraints) describes this allocation of current requirements and decision provenance. The Cookies example uses a shared cookie-management component through which application code reads, sets, and removes cookies. Engineering guidance requires contributors to use that component and defines how new cookie behavior is added. Its decision record explains the control's coverage and limitations, including legacy cookies, third-party code, and execution contexts outside that coverage. Material remaining risk is addressed or accepted by the assigned authority. The component can be reused while its requirement, applicability, and supporting assumptions hold. New data, purposes, recipients, or trust relationships require an applicability check. Experience with a component informs its expected operation; the current assessment establishes whether it remains adequate for the proposed use. ### 4.2. Requirement Interactions Security and privacy requirements participate in the same Standing Requirement system as other product obligations. Their records identify material dependencies and competing demands on the same behavior. The relevant decision owners determine how the applicable obligations can be satisfied together and record the resulting conditions or an authorized exception. The following perspectives identify common interactions to examine. 1. **Retention and evidence** Identify which records establish compliance, why they are retained, who may access them, and which deletion rules apply to each data class. 2. **Reliability and recovery** Determine how restored data remains subject to current authorization, retention, and withdrawal requirements. 3. **Architecture and integration** Confirm the recipients, services, and execution contexts covered by the control, including newly introduced data flows. 4. **Product behavior** Define how the product continues to serve the user when an optional capability, such as remembering preferences through cookies, is unavailable or declined. In the Cookies example, preference values and evidence of a consent decision serve different purposes. The decision owners specify the treatment of each so that withdrawal ends the relevant use and removes the classified preference cookies while any separately justified evidence is handled under its own approved rule. The functional specification can then express the agreed outcomes for each data class. The team records the relationship between these requirements and the decision resolving their interaction. If either requirement changes, that relationship identifies the other decision owner and affected specifications. Reuse consequently includes maintaining the agreements on which several requirements depend. ## 5. Derivation of Increment Functional Specifications An increment's functional specification defines observable behavior, scenarios, exceptions, and acceptance conditions. The people preparing it identify the applicable Standing Requirements, confirm their assumptions and interactions, and resolve material gaps before dependent implementation begins. The Cookies example illustrates how that work starts from a specific legal and product context. For a product subject to the relevant United Kingdom rules, guidance from the Information Commissioner's Office (ICO) explains consent and exceptions for cookies and related browser technologies.[^citation-09] The Product Owner or Product Manager and relevant specialists use applicable guidance to confirm the classification and obligations for the intended cookie use. The example proceeds with the consent requirement established earlier; its treatment of preference cookies is an approved scenario assumption. The Standing Requirement establishes the withdrawal outcome and cessation of the relevant processing. The increment specification defines how its states and transitions deliver that outcome. Policy or Governing Instructions can require coverage of the relevant states; the functional specification supplies their precise behavior. The following records illustrate what an increment introducing another optional preference must establish within the approved classification. 1. **Consent has not been established** The feature works without setting or using the classified preference cookies. - **Behavior to specify:** Define the current interaction and the handling of legacy preference cookies while valid consent is absent. - **Verification:** Observe initial use and page reloads, including a browser that already contains legacy cookies. 2. **Consent is granted** The feature remembers only the approved preferences for their stated purpose. - **Behavior to specify:** Identify which cookies may be set and read, and the effect on the current interaction. - **Verification:** Inspect cookie values and subsequent behavior against the approved data and purpose. 3. **Consent is declined** The feature provides the approved experience without the optional preference cookies. - **Behavior to specify:** Prevent the classified cookies from restoring preferences and define the resulting user experience. - **Verification:** Exercise the feature and reload the page after refusal. 4. **Consent is withdrawn** The affected use ends and the classified preference cookies are removed. - **Behavior to specify:** Define when withdrawal takes effect, removal of the affected cookies, and the result for an active interaction. - **Verification:** Inspect cookies and behavior after withdrawal, then repeat relevant access paths and page reloads. 5. **The consent record is unavailable or invalid** The feature applies its approved behavior for absent valid consent. - **Behavior to specify:** Define the resulting state and cleanup, keeping evidence of consent separate from the presence of preference cookies. - **Verification:** Exercise missing or invalid consent records and expiry where the approved rules define it. 6. **The browser blocks cookies** The feature preserves the privacy conditions while using the approved fallback or failure behavior. - **Behavior to specify:** Define how the interaction proceeds when cookie operations fail or are unavailable. - **Verification:** Exercise blocked cookies and inspect the resulting behavior and any fallback. The actual specification settles timing, active-session behavior, multiple-tab effects, and failure handling wherever they can change the result. Analysts and product participants establish that behavior with the relevant specialists. Architects and engineers determine design and implementation responsibilities, and quality professionals connect each material condition to verification. If implementation reveals a cookie access path outside the approved control or a conflicting retention rule, the participant returns the finding to its decision owner and the specification is revised through the agreed authority. ## 6. Verification and Knowledge System Maintenance ### 6.1. Conformance and Acceptance Verification examines the specification's coverage of applicable requirements and the software's conformance to that specification. In the Cookies example, code inspection can establish whether application code uses the shared cookie-management component. Behavioral evidence must also establish that the user's choice produces the agreed result in the recorded consent, affected cookies, and subsequent feature behavior. That relationship between choice and execution has been examined empirically. Matte, Bielova, and Santos studied cookie banners using IAB Europe's Transparency and Consent Framework, which communicates consent choices to participating services. They found implementations that recorded positive consent before a choice or despite refusal.[^citation-10] Their findings expose a failure mode that a check for the presence of a banner or shared component would miss. Acceptance of the example feature therefore needs evidence of the relevant behavior after consent is granted, declined, or withdrawn. The accountable acceptance role reviews that evidence, deviations, and required specialist judgments. The Product Owner or Product Manager remains accountable for product compliance, including whether the requirements adequately address the product's circumstances. [Trusted Increments and Acceptance Evidence](/en-us/hub/trusted-increments-and-acceptance-evidence) develops the wider method for connecting requirements, responsibilities, verification, and evidence to an acceptance decision. ### 6.2. Periodic Review and Source Changes Security and privacy requirements follow the periodic review process in [Standing Product Requirements and Constraints](/en-us/hub/standing-product-requirements-and-constraints). Each requirement or governed group records its last substantive modification, last completed review and outcome, expected next review date, and review responsibility. The owner selects an interval appropriate to the obligation and consequences, with event-triggered reviews addressing material changes between scheduled reviews. The review examines whether the product context, specialist interpretation, threat assessment, controls, and residual risk judgment still hold, including their interactions with other requirements. For a product subject to GDPR, for example, the EDPB's Article 25 guidance calls for regular review of the effectiveness of data-protection measures throughout processing.[^citation-04] The team identifies the review obligations applicable to its own product and records the result through the common Standing Requirement process. Where the product relies on maintained upstream sources, a sweep job checks them and identifies changes that may affect the approved interpretation. Its record shows the source and version checked, the time, and the result. A professional review then determines whether the requirement remains valid for the product. Source checks and professional reviews retain their own outcomes, including when a review confirms the existing requirement without changing its content. In a repository-centered implementation, each product-specific requirement derived from policy or law can carry review metadata in its document or a linked requirement index. Fields such as `reviewOwner`, `lastReviewedAt`, `nextReviewAt`, `source`, and `sourceVersion` make the owner, review schedule, and governing input discoverable. The decision owner chooses the interval and records the next review date when confirming the requirement. A governed document platform can maintain equivalent information. A scheduled AI job can prepare the review through the following procedure: 1. Read the requirement index and identify reviews that are due or overdue, together with relevant source-change notifications and recorded product changes. Report missing review dates or inaccessible sources to the assigned owner. 2. Compare the authoritative sources with the versions used in the current requirements. Prepare a review brief containing source links, observed changes, potentially affected assumptions or controls, related requirements, and unresolved questions. Record a source-check result even when no change is found. 3. Route the brief to the person assuming product responsibility and the relevant specialist decision owners. They assess the current product context, confirm or revise the requirements, and record the completed review, its outcome, the next review date, and any downstream work. The job's assigned authority covers discovery, comparison, and preparation of proposed updates. Completion of the scheduled job records that preparation; the professional decision establishes whether the requirement remains valid. In the Cookies example, a review can be due even when published guidance is unchanged, because a new feature or third-party integration may have changed how the preference cookies are used. ### 6.3. Change Impact and Retained Knowledge When a review identifies a material change, the decision owner assesses its effect on the requirement and dependent knowledge. Related Standing Requirements need attention where a shared assumption, control, or previously resolved conflict has changed. Increment specifications and existing software need review where their behavior relies on the superseded interpretation. Maintain the requirement and its dependent product knowledge through the existing decision and delivery process. 1. **Identify the change** Record the changed source, assumption, data flow, threat, or control finding and route it to the responsible decision owner. 2. **Assess the consequences** Determine whether the requirement remains valid and identify affected requirements, specifications, controls, software, and evidence. 3. **Confirm the response** Record the approved interpretation, effective conditions, residual risk decisions, and any required remediation or restriction on dependent work. 4. **Retain the result** Update current knowledge and its links, record the review outcome and next review date, and verify the changes required of the software. In the Cookies example, introducing analytics may require a revised privacy assessment, changes to Standing Requirements and control coverage, and new functional behavior. The review identifies those consequences and their owners, including any remediation of previously accepted software. The requirement's current status and the software's conformance status remain separately visible. A material unresolved effect must be addressed before dependent work is approved on that basis. Existing effective dates and exception expiry conditions continue to apply during review. Findings from implementation, verification, and operation return to the Knowledge System through [Knowledge Convergence Across the Increment Lifecycle](/en-us/hub/knowledge-convergence-across-the-increment-lifecycle). ## 7. Conclusion Security and privacy requirements make professional judgment reusable when they express the product's obligations, applicability, assumptions, and expected evidence clearly enough for subsequent delivery. Specification-First Delivery carries this knowledge through the full sequence: the person assuming product responsibility combines specialist advice with product context, the relevant decision owners confirm the Standing Requirements, and each applicable increment derives the behavior and verification needed to satisfy them. The Cookies example shows how that sequence connects a consent obligation to observable behavior across user choices and later product changes. Continued reuse depends on maintaining the judgment as well as its implementation. Source checks, periodic reviews, and recorded relationships between requirements allow the team to reassess changed assumptions, coordinate obligations, and identify affected specifications and software. AI can assist with that work while qualified people retain the relevant decisions. The resulting Knowledge System gives future contributors an approved interpretation to apply and a clear route for questions that require renewed judgment. The proportionality treatment in [Standing Product Requirements and Constraints](/en-us/hub/standing-product-requirements-and-constraints) guides the depth of preparation and review. The unfamiliar-participant test in [Knowledge System Readiness](/en-us/hub/knowledge-system-readiness-for-specification-first-delivery) examines whether another qualified participant can use the resulting knowledge to continue responsible delivery. [^citation-01]: Christian, T., and Mead, N. R. (2010). *Security Requirements Reusability and the SQUARE Methodology*. CMU/SEI-2010-TN-027. Software Engineering Institute, Carnegie Mellon University. [Report and DOI](https://www.sei.cmu.edu/library/security-requirements-reusability-and-the-square-methodology/). [^citation-02]: National Institute of Standards and Technology. (2020). *NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0*. NIST CSWP 01162020. [Full text](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf). [^citation-03]: National Institute of Standards and Technology. (2024). *The NIST Cybersecurity Framework (CSF) 2.0*. NIST CSWP 29. [Publication](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final). [^citation-04]: European Data Protection Board. (2020). *Guidelines 4/2019 on Article 25 Data Protection by Design and by Default*. Version 2.0, adopted October 20, 2020. [Full text](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf). [^citation-05]: Danezis, G., Domingo-Ferrer, J., Hansen, M., Hoepman, J.-H., Le Métayer, D., Tirtea, R., and Schiffner, S. (2014). *Privacy and Data Protection by Design: From Policy to Engineering*. ENISA report, December 2014; publication page dated January 12, 2015. [Report](https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design). [^citation-06]: Deng, M., Wuyts, K., Scandariato, R., Preneel, B., and Joosen, W. (2011). A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements. *Requirements Engineering*, 16, 3–32. [DOI: 10.1007/s00766-010-0115-7](https://doi.org/10.1007/s00766-010-0115-7). [^citation-07]: National Institute of Standards and Technology. (2012). *Guide for Conducting Risk Assessments*. NIST SP 800-30 Rev. 1. [Publication](https://csrc.nist.gov/pubs/sp/800/30/r1/final). [^citation-08]: Hoepman, J.-H. (2014). Privacy design strategies. In *ICT Systems Security and Privacy Protection*, IFIP Advances in Information and Communication Technology, 428, 446–459. [DOI: 10.1007/978-3-642-55415-5_38](https://doi.org/10.1007/978-3-642-55415-5_38). [^citation-09]: Information Commissioner's Office. (2026). *Guidance on the Use of Storage and Access Technologies*. Updated April 29, 2026; accessed September 12, 2026. [Guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/). [^citation-10]: Matte, C., Bielova, N., and Santos, C. (2020). Do cookie banners respect my choice? Measuring legal compliance of banners from IAB Europe's Transparency and Consent Framework. *IEEE Symposium on Security and Privacy*. [Author manuscript](https://arxiv.org/abs/1911.09964).