Privacy Requirements Definition and Testing

Definitions: Privacy requirements are statements that reference key privacy objectives (e.g., Fair Information Practice Principles, or FIPPs) and specify capabilities and functions that a system must be able to perform. Like other system requirements, privacy requirements are actionable, measurable, testable, and traceable. When built into a system, privacy requirements substantiate a system’s compliance with fundamental privacy objectives and applicable privacy regulatory guidance.

Privacy testing is the process of verifying that a computer system meets the privacy requirements used to help design and develop the application. It is a preemptive step to ensure that systems are properly designed to protect Personally Identifiable Information (PII) and then work as expected. In the absence of testing, other verification techniques ("testing activities") such as code and document reviews are used. Privacy testing is part of the existing requirements definition and testing process, not a separate process. Privacy testing is fundamentally the same as other types of testing performed on the system. The only difference is a privacy focus.

Keywords: privacy, requirements engineering, systems engineering

MITRE Systems Engineers (SE) Roles and Expectations: MITRE systems engineers (SEs) are expected to recognize when privacy is within the scope of the system being developed. They should work with the sponsoring organization and privacy subject matter experts to translate the agency’s privacy principles, policies, and procedures into actionable engineering requirements applicable to the focus of the system. MITRE SEs are expected to develop test cases in concert with the privacy requirements that will enable the successful implementation of the privacy requirements to be verified. They are expected to incorporate privacy requirements and privacy test cases within existing systems engineering artifacts for formal integration within the project.

Background

Privacy considerations are a critical element of government programs and systems that collect and use personally identifiable information(PII). Failing to address privacy risks may result in, at the very least, a distraction from agency activities that support the mission and, at the worst, the termination of important programs or costly breaches that bring harm and embarrassment to both individuals and agencies. The traditional model for addressing privacy risks relies on providing public notices (e.g., Privacy Act System of Records Notices, Privacy Act statements), conducting Privacy Impact Assessments (PIAs), and more recently, training and breach management programs. This model, though useful and important, places a degree of faith in underlying information systems that assumes they adequately support high-level privacy tenets, such as the FIPPs, without a direct method to document privacy requirements and verify technically that PII is both protected and handled in accordance with privacy principles. The process of privacy requirements definition and testing addresses that gap. For more information on the FIPPs, see the Privacy Engineering article.

Testing is a well-developed practice in software engineering, information security, and safety-critical systems. Until recently, however, the notion of privacy testing has been little explored. Yet, increased emphasis on privacy in systems development implies just as much need for an approach to privacy testing as for security testing, as well as software generally. The purpose of testing is to ensure that system requirements, including privacy requirements, have been built into the system and that the system behaves as expected. Benefits of privacy testing include:

Identifies privacy issues prior to production, including those that may not have been apparent in the system design, which:

Provides input for the actions required to ensure satisfactory resolution of privacy risks and issues.

Reduces the cost of mitigating privacy issues by catching them early in development.

Establishes confidence with stakeholders by demonstrating due diligence.

Encourages collaboration among privacy, security, and business personnel in the agency.

The approach for conducting privacy testing in this article is designed to fit into the typical systems engineering life cycle (SELC) model along with other types of system verification and testing activities. (See the SEG's Privacy Engineering article.) The results of privacy testing inform other system design and development activities as well as special forms of risk management activities such as the security assessment and authorization (SA&A) process and PIAs, as illustrated in Figure 1.

Figure 1. Examples of Activities That Privacy Testing Informs

Although privacy testing is an input to risk management activities, it is important to distinguish between the two. Privacy testing discerns whether discrete system requirements have been properly built into a system, whereas risk management activities examine risks to make decisions about acceptable levels of overall system risk. Risk analyses such as PIA and SA&A are not equivalent to testing nor do they obviate the need for testing.

Privacy testing and security testing do overlap where the requirements of the two disciplines intersect, but privacy tests focus specifically on areas of privacy that are separate and distinct from security tests commonly employed in the SELC. Security remains integral to implementing privacy requirements; however, privacy requirements extend the standards for security requirements and controls to ensure that FIPPs are properly addressed.

Privacy requirements development and privacy testing bring to life some of the concepts and intent behind the Privacy by Design (PbD) movement. Privacy testing takes the very general foundational principles of PbD and turns them into a rigorous, precise, consistent method of system verification that is grounded in existing approaches. Privacy testing is an important action to complete in order to ensure that systems protect PII. A Privacy Engineering Framework should describe the different activities to be completed within each system development life-cycle stage to ensure that privacy is built into a system. (For more information on the framework, see MITRE's privacy program.) Privacy requirements definition and testing are two such activities.

Process

The process for conducting privacy requirements definition and testing takes advantage of the fact that the key privacy objectives (e.g., FIPPs) and associated top-level system requirements and test/verification methods are fairly universal and readily adaptable to the specifics of most systems. System owners can tailor these general privacy objectives, requirements, and tests to their system's purpose and characteristics. The process has four main steps:

Table 1. Sample Privacy Requirements

Privacy Objective

Privacy Requirement
Level 1: General System Interpretation

Privacy Requirement
Level 2: Specific System Requirement

Minimization of PII

PII in the system shall meet the authorized, documented purposes of the system.

For systems that collect PII from source systems or third parties, the system shall support a method of tracking consent when appropriate.

Redress

The system shall support the tracking of disputed PII.

When the individual disputes the accuracy of PII or any output based on the disputed PII, the system shall maintain a flag indicating that the PII is in dispute.

Table 2. Sample Privacy Requirements and Associated Privacy Tests

Privacy Objective

Privacy Requirement
Level 1: General System Interpretation

Privacy Requirement
Level 2: Specific System Requirement

Privacy Test/Verification Method

Minimization of PII

PII in the system shall meet the authorized, documented purposes of the system.

The system shall only collect and use PII relevant to its purposes.

Review system data model and database architecture and associate each PII data element or logical aggregate of elements (e.g., mailing address) with a rationale for its inclusion.

Consent

For systems that directly interface with individuals, the system shall distinguish between mandatory and voluntary PII collection.

For systems that collect PII from source systems or third parties, the system shall support a method of tracking consent when appropriate.

Create test record with the consent flag enabled and one with the consent flag disabled. Attempt to execute an action that requires use of the consent flag.

Redress

The system shall support the tracking of disputed PII.

When the individual disputes the accuracy of PII or any output based on the disputed PII, the system shall maintain a flag indicating that the PII is in dispute.

Submit test PII to the system. Subsequently submit a dispute of the same PII.

Select Privacy Requirements: System owners should work with privacy professionals in selecting the specific privacy requirements to ensure that all aspects of privacy for the system’s environment are addressed. Aspects to consider include laws or guidance with privacy provisions that apply only to specific environments, such as the Taxpayer Browsing Protection Act, which applies only to the IRS; Title 13 of the U.S. Code, which applies only to the Census Bureau; and the Health Insurance Portability and Accountability Act (HIPAA), which applies to specific entities in the healthcare environment. Table 1 provides sample privacy requirements for several key privacy objectives:

Minimization of PII

Consent

Redress

Select and Tailor Privacy Tests: Each privacy test should be reviewed by system testers and tailored to the specifics of the system implementation and the development environment. The exact nature of the privacy tests, including pass/fail conditions, should be documented in the test plan. Table 2 provides sample privacy test/verification methods for the Table 1 sample privacy requirements.

Conduct Privacy Tests: The goal of privacy testing is to ensure that the software works as expected to protect PII. How tests are executed depends on the requirement being tested and the technologies the system uses. Tests may be executed by running transactions through the system and examining results, or using automated tools. In some cases, privacy requirements cannot be verified via system tests. Instead, verification techniques such as code review, design specification review, requirements specification review, and concept of operations review are used in verification.

Analyze Results: Privacy analysts, working with the system owners, system developers, and testers, determine appropriate actions to mitigate the privacy risks of failed or inconclusive tests. Test results are also fed into system privacy risk metrics for the system that are then used as input for the completion of PIAs.

Best Practices and Lessons Learned

Privacy requirements definition and testing are not fundamentally different from other aspects of system requirements definition and testing. Some aspects are specific to privacy just as other aspects are particular to security, performance, etc. Privacy requirements based on the details of the system are incorporated into the design, implemented, and verified. These processes make use of the standard systems engineering tools, including requirements traceability matrices, design and code reviews, and executable test cases. Because privacy is so focused and dependent on data flows, successfully defining and verifying privacy requirements may necessitate more systematic and holistic representation and analysis of data flows (where the data is PII) than a project might otherwise require. Further, because privacy can be a somewhat diffuse property, multiple forms of verification may be necessary to provide sufficient assurance (a “preponderance of evidence” approach). However, the overall process should be familiar to any SE.

In principle, privacy requirements definition and testing should be incorporable into most life-cycle methodologies. This is relatively straightforward for traditional, waterfall life cycles, but it may be more complicated for other life cycles that are more iterative or incremental (see the articles under the SEG's Program Acquisition Strategy Formulation topic for a discussion of life-cycle models). In those cases, privacy requirements definition and testing activities will need to track the system functionality with which they are associated or on which they are dependent. Guidance relating to specific life cycles will need to include appropriate procedures for doing this, whereas general guidance will need to incorporate relevant elements as well. In particular, documentation standards and templates must explicitly capture information relevant to privacy requirements definition and testing.

References and Resources

e-Government Act of 2002, Public Law 107-347.

Health Insurance Portability and Accountability Act (HIPAA), Public Law 104-191.

MITRE intends to maintain a website that is fully accessible to all individuals. If you are unable to search or apply for jobs and would like to request a reasonable accommodation for any part of MITRE’s employment process, please contact MITRE’s Recruiting Help Line at 703-983-8226 or email at recruitinghelp@mitre.org