Privacy & Data Protection

Home » Privacy & Data Protection

The Office of Privacy and Data Protection was created by executive order to help ensure state agencies comply with state public records and open government laws, while seeking to protect personal information to the maximum extent possible.

The office’s responsibilities include conducting an annual privacy review, providing privacy training for states employees and promoting data minimization. Please check out the links below for privacy tips and to learn more about this office.


Tips, Tools and Checklists

WaTech has curated a variety of information on online privacy. While we cannot endorse any particular product or service, you may find the following tips helpful:

Using your Computer's Basic Tools

Computer use is ubiquitous in state government and agencies. Having strong acceptable use policies can help protect against the significant security, privacy, and other threats to an organization. It is recommended that every organization have an acceptable use policy for computers, tablets, phones, and other mobile devices, whether they are owned by the organization or privately by the employees themselves and brought to work.

  • Sort employee roles into groups with similar computer use needs
    • Ex: social media access may be needed by marketing groups and thus require a more liberal policy, whereas other groups may have no relevant use for social media, of which its use will either be outside the scope of their work and be a potential security concern.
  • Assess whether employees need to download software
    • Ex: downloading software can be made off limits, or an approval process can be created where employees can request to download certain programs, which are first reviewed by IT and management.
  • Establish how you will limit access
    • This can be achieved with technical controls, such as blocking certain websites. Companies can rely on trusting employees to use their best judgement but need to remain aware of the risks of not limiting access.
    • Assess the severity of the violations including but not limited to: loss of productivity, security concerns, monetary damages
    • Determine how difficult it would be to set up the controls
  • Address the issue of social media directly
    • The acceptable use policy should explicitly address use of social media sites during work hours and at work.
      • Note, some employees may have a legitimate work need for social media, make exceptions based on the department and employee necessity.
  • Create an informative policy regarding acceptable social media and blog posts, both during and outside of work
    • Keep in mind employees have a first amendment right to post on social media sites and other sites
    • Employers are allowed to restrict posts regarding:
      • Private and sensitive information;
      • Proprietary information.
  • Establish appropriate repercussions for violating the policy
    • Ensure employees are aware of the repercussions.
  • Establish a training policy to ensure employees comprehend and follow the policy
    • Employees can only follow a policy if they have understand and comprehend the policy
  • Explain why the policy exists so employees will be more likely to abide by the policy
    • Tip: Tutorials that require active participation are a good strategy for policy comprehension

Devices, Home Automation and the Internet of Things

Adapted from guidance published by the Office of the Information and Privacy Commissioner for British Columbia

Installing surveillance equipment may seem like a logical decision for your organization, but collection and use of personal information through video surveillance may violate privacy law and could lead to other costly liabilities.

  • Identify and document the purpose that may be served by surveillance
  • Limit the time your surveillance is active, for example:
    • turning on the cameras for certain times of the day or night rather than 24 hours a day
  • Avoid unintended subjects
    • Position cameras to capture the least amount of information that is needed. For example, a store security camera should not capture images of passersby on the street.
    • Avoid areas where people have a heightened expectation of privacy, such as change rooms, washrooms, or into windows.
  • Draft and adopt an organizational policy that addresses:
    • the rationale and purpose of the surveillance
    • when and how monitoring and/or recording will be in effect
    • how recordings will be used
    • for how long they will be kept
    • how they will be securely deleted
    • process to follow if there is unauthorized access or disclosure
  • Limit access
    • identify individuals who are authorized to access the recordings.
    • Authorized individuals should only review the recorded images to investigate a significant security or safety incident, such as criminal activity.
    • Minimize the number of individuals who have access to the monitoring system or recordings, and
    • Provide ongoing privacy training so operators are clear about their obligations
    • Any disclosure of video surveillance recordings outside your organization should be limited to that authorized by the applicable privacy law, and be documented.
    • Be prepared to provide a copy of the relevant surveillance recording upon request.
    • When disclosing recordings, use masking technology to ensure that identifying information about other individuals on the recording is not disclosed.
  • Storage and destruction
    • To reduce the possibility of loss and theft, keep video recordings under your control - either on trusted premises or on a trusted cloud platform.
    • Develop and follow a secure storage protocol.
    • Prepare a retention and destruction schedule to specify the length of time that surveillance records will be kept (we recommend a maximum of 7 days).
    • Decide when and how records will be destroyed.
    • Safely and securely destroy recorded images when they are no longer required for business purposes.
    • Document the destruction in your logs.
  • Camera Accountability
    • Post a clear, understandable, and visible notice about the use of cameras on the premises before individuals enter the premises.
    • The sign should plainly indicate which areas are under video surveillance and for what purpose, for example: "This property is monitored by video surveillance for theft prevention."
    • Provide contact information of someone in your organization for individuals to contact if they have questions about the surveillance.
    • Consider making your written surveillance policy available to the public.
    • Regularly review your policy to ensure that using video surveillance is still justifiable and needed for your original purpose (we recommend a biennial review).

Laws, Rules, and How They're Made

While it is most likely Agencies will not come under GDPR scrutiny, it is still important to know the risks and how to avoid them. This checklist provides a quick primer on issues that will open an agency to GDPR violations and how to avoid those pitfalls.

  • Is the Agency monitoring European residents data by controlling and/or processing data belonging to European residents?
    • If no, then stop, the GDPR does not apply
    • If yes, then continue.
      • Note: A processor is an entity who processes the data on behalf of the controller, this includes data organization and storage.
      • Note: A controller is the entity whom decides how the personal data will be processed and for what purpose it will be used
  • Is the agency buying or obtaining data from third parties?
  • Does the data include information on European Residents?
    • If yes, then the agency should stop collecting data on those persons, purge the system of data on those persons, determine if they need the data, and potentially contact an attorney.
  • Is the agency sharing data with third parties in which some data pertains to European Residents?
    • If yes, the agency needs to have a business purpose for doing so.
  • If the collection, processing, and retention of the data is for the following points then the agency maybe allowed to collect, process, and retain the data.
  1. national security;
  2. defense, public security, the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security;
  3. other important objectives of general public interest of the State, in particular an important economic or financial interest of the State, including monetary, budgetary and taxation matters, public health and social security;
  4. the protection of judicial independence and judicial proceedings;
  5. the prevention, investigation, detection and prosecution of breaches of ethics for regulated professions;
  6. monitoring, inspecting or regulatory function connected, even occasionally, to the exercise of official authority;
  7. the protection of the data subject or the rights and freedoms of others;
  8. and the enforcement of civil law claims.
  • If the purpose for collecting, processing, and retaining data is for the purpose(s) above (a-h), and includes European Union Residents, the agency must provide an explanation as to why the restriction(s) is necessary.
  • If the agency is not collecting any personal information on EU residents then the Agency will NOT be subject to GDPR compliance.
  • It is important to keep in mind that Washington has a lot of foreign workers and if they were to return to the EU the agency should have a process by which they destroy that personal information, or provide a user notice telling people about the retention of personal data after they have departed Washington.

The Controlling the Assault of Non-Solicited Pornography and Marketing Act (“CAN-SPAM Act”) is a federal law enacted in 2003. It sets out requirements for businesses and or people who are soliciting services or products via commercial mail to potential consumers.  Commercial mail is defined as “any electronic mail message the primary purpose of which is the commercial advertisement or promotion of a commercial product or service.”

This checklist was assembled by Logan Peppin at the UW Privacy Law Clinic

Covered by CAN-SPAM?

Step 1: Ask yourself: Are you a company that is soliciting a product or service via email to prospective consumers?

  • If no, CAN-SPAM is not applicable to your company. Stop.
  • If yes, proceed to step 2.

Purpose of email

Step 2.   Identify what is the purpose of your email?

  • Commercial – advertising;
  • CAN-SPAM applies;  Go to step 3
  • Transactional – already agreed upon communication with a customer;
  • CAN-SPAM does not apply; stop
  • Other -
  • CAN-SPAM does not apply; stop

Content of email

Step 3. Content of E-mails. Every email that solicits a service needs these things:

  • Accurate Header Information
    • No misleading/false information
    • To/From must be correct
    • Accurate Subject Lines
  • Disclosed as an ad -- Must be “clear and conspicuous”
    • Companies physical postal address
    • A clear opt-out 
    • EX: bottom of email an unsubscribe button to click
    • Consider the font color, size, and style

Special spam steps

Step 4: consider special requirements and risks

  • If this is a sexually explicit email, there are other requirements you must follow
  • You can still be liable for email sent by a hired third party who is in charge of promotional messages.  
    • If someone opts out and tells the third party, you are also liable for your contractor's failure.
  • Email sent to a phone are still subject to CAN-SPAM
  • SMS text messages are NOT subject to CAN-SPAM

Under State Technology Policy 141.10, Agencies must classify data into categories based on the sensitivity of the data. This checklist helps Agencies determine what type of data they are collecting and the proper handling of that data.

The following are four categories which your data will fall under. If you cannot establish the proper category for your data there are resources listed at the end of the checklist you can contact who can help you with the categorization.

Category 4, “Confidential information requiring special handling,”

if you can reasonably answer "yes" the following two questions then you are included in category 4

  1. Does the data have any especially strict handling requirements applied by statutes (such as HIPAA) or regulations (such as Rules on employee files) or agreements?
  2. Would serious consequences arise from unauthorized disclosure, such as threats to health and safety, or legal sanctions?

Category 3 “Confidential information,”

  1. if your data was NOT covered under category 4 then evaluate whether it is covered under category 3. Under category 3 the information is specifically protected from either release or disclosure by law
  2. Is the data “Personal information” as defined in RCW 42.56.590 (security breaches) and RCW 19.255.010 (personal information disclosure)?
    • an individual's first name or first initial and last name in combination with any one or more of the following data elements:
    • Social security number
    • Driver's license number or Washington identification card number
    • Full account number,
    • credit or debit card number, or
    • any required security code, access code, or password that would permit access to an individual's financial account
  3. Is the data about public employees as defined in RCW 42.56.250? This could include:
    • Test questions, scoring keys, and other examination data
    • Applications for public employment,
    • Professional growth plans (PGPs) in educator license renewals
  4. If the data is held by a public agency in personnel records, does it contain any of the following about home health care workers, employees, or volunteers of a public agency or their dependents?
    • Residential addresses,
    • residential telephone numbers,
    • personal wireless telephone numbers,
    • personal email addresses,
    • social security numbers,
    • driver's license numbers,
    • identicard numbers, and
    • emergency contact information
  5. Evaluate whether the data basically a list of individuals?
    • and is it NOT a list of licensees or applicants; and
    • is the requestor NOT the profession’s recognized licensing or examination board; and
    • was it requested for commercial purposes?
  6. Does the data concern the infrastructure and security of computer and telecommunication networks?
  7. If you are unsure if your data fits in any of the above listed groups comprising category 3 then consult these resources:
  8. Does your agency have specific public records requirements that have to be considered?  For example, sensitive species habitats at Fish and Widlife.

Category 2, “Sensitive information,”

if your data is not covered in the above category then consider whether it is covered under category 2. Answering "yes" to both of the following questions indicates your information is covered under this category”

  1. Is the data intended for official use only?
  2. Is it usually withheld unless specifically requested?

Category 1 “Public Information,”

if your information is not covered under Category 4, 3 or 2 then it is probably under Category 1 or even “Open Data.” The following are characteristics of public information:

  • Is the information already released to the public – such as through a previous public records request?
  • If not, does the agency believe it should be released rather than protected?
  • Public doesn’t mean worthless – public data does need integrity and availability protection

Still not sure it’s Public data? Consult these resources:

  • Your organization’s Privacy Officer
  • Your organization’s Records Officer
  • Your organization’s Open Data Plan
  • Our checklist on Publishing Open Data
  • OCIO guidance on what to publish first

The purpose of this rubric is to (1) assess the existence and completeness of key components of a data governance manual, and (2) identify areas and recommendations for further development. The rubric may be used as a self-assessment, or by a third party.

The rubric contains multiple sections as and allows additional recommendations:1) Purpose, 2) Structure, and 3) Policy and Practice.

Each section contains components that are important to include within a comprehensive data governance manual. Reviewers indicate whether the component is Fulfilled or has Action(s) Recommended. Fulfilled indicates the component is adequately represented in the manual though enhancements may be suggested in the comments; Action(s) Recommended indicates the need for additional information as explained in the comments. The data governance manual is one critical output of a data governance program, but there are many other elements that must be in place for data governance to be successful, and that may not be reflected in the data governance manual alone.

OSPI Governance - Purpose

Clarifying and documenting the intended purpose and scope of data governance is important to ensure that all data governance members and stakeholders have common expectations for the program.

  • Purpose: There is a defined purpose (e.g., mission, core principles, goals, objectives) for data governance that describes how it and the data system support the state's or agency’s policy and program goals.
  • Scope: The universe of data overseen by the data governance program is defined.
  • Value: The value of the data governance program and data system to the organization and stakeholders is articulated.
  • Use of Data: How data governance supports the use of data to inform decisions is described, as well as the types of data uses the system will enable.
  • Data Users: The role(s) that are intended to use the data from the system are identified.

OSPI Governance - Structure

Clearly defining the data governance structure, including roles, responsibilities, and relationships among groups, is important to ensure data governance members understand their role within the broader program, and that the appropriate representation and decision-making authority exists.

  • Data Governance Structure: The structure is defined and includes at least a leadership/policy-level group and an implementation-level group.
  • Non-Voting Roles: If applicable, the responsibilities and expectations of a non-voting role on the data governance group(s) for key stakeholders (e.g., researchers or other non-data contributors) are defined.
  • Relationships to Outside Groups: If applicable, the relationships and communication between the data governance program and external advisory or stakeholder groups are defined.
  • Frequency of Convening: The convening frequency of each data governance group is defined and documented.
  • Representation: Every agency or program area responsible for data overseen by the governance program has representation on all data governance groups.
  • Authority: The role, responsibilities, and decision-making authority of each data governance group are described.
  • Relationships Among Groups: The relationships (including issue escalation/resolution) and communication mechanisms among the data governance groups are defined.
  • Data Governance Coordinator: A coordinator role is defined with core responsibilities, including leading the implementation-level data governance group(s) and serving as the liaison between the data governance groups.
  • Member Responsibilities and Expectations: Concrete responsibilities and expectations of the members of each data governance group are defined.
  • Data Stewardship: Each data steward has a clearly defined scope of data elements for which he/she is responsible.
  • Member Selection: Criteria for membership in each data governance group are documented, including how members are selected and rotated (if applicable) and the addition of new members as the system evolves.
  • Member Induction: The data governance program has a documented induction process for new members to familiarize them with the data governance manual, policies, and processes, and their responsibilities and expectations.

OSPI Governance - Policy + Process

Defining how the data governance groups will make decisions and resolve issues is essential to a functional data governance program because it determines how the work will be accomplished.  In addition, establishing data policies and processes is a critical focus of a data governance program because it ensures that data will be managed purposefully and consistently throughout the information lifecycle in support of the data governance program purpose.

Note: The policies and processes may not be fully documented as part of the data governance manual, but at minimum, the manual should reference/link to where they exist.

  • Decision-Making Model for Each Group: Each data governance group has a documented decision making model (e.g., majority vote, 2/3 vote, consensus model) including if there is a required threshold of representation for a decision to be made.
  • Data Collection: The data governance program ensures the documentation (by all agencies involved, if multi-agency data governance) of the process to prepare and submit data to the system, including the timeline and resources required.
  • Data Expansion: The data governance program has documented the policy and process for adding additional data to the system.
  • Data Quality: The data governance program has documented policies and processes to ensure that data are accurate, complete, timely, and relevant to stakeholder needs.
  • Data Use Priorities: The data governance program has a documented research or data use agenda that is used to prioritize the creation of data products and the response to external data requests.
  • Data Request: The data governance program has a documented data request policy and associated process for submitting, reviewing, approving or denying, and fulfilling data requests.
  • Data Release and Reporting: The data governance program has a documented data release policy and associated process for ensuring that data and data products from the system have been (1) validated by the appropriate members and (2) are created in accordance with reporting standards to ensure sufficient data privacy, quality, and consistency over time.
  • Data Sharing Agreements: The data governance program oversees the establishment, maintenance, and enforcement of data sharing agreements.
  • Data Issues: The data governance program has a documented process for identifying, prioritizing, escalating, and resolving issues that inhibit data quality and data use.
  • Documentation of Decisions: The data governance program decisions and issue resolutions are documented and stored in a place accessible by all data governance members.
  • Manual Development and Maintenance: All data governance members have an opportunity to review and provide input into the draft data governance manual before it was finalized and as part of each (at minimum annual) update. The executive leadership level data governance group officially approves the manual.
  • Adding New Participating Entities: The data governance program has a documented policy and associated process for proposing, reviewing, approving, and inducting new entities to the SLDS, including criteria for eligibility. *
    • Only relevant for multi-agency DG programs.
  • Metadata: The data governance program has a documented process for maintaining and making available metadata, including a data collection/refresh calendar and data dictionary. 
  • Master Data Management: For enterprise data elements contributed by more than one source, the data governance program has determined and documented the source of record.
  • Data Matching: The data governance program has a documented data matching process, including quality controls to reduce over- and under-matching.

OSPI Governance - Use and Disposition

Related to Policy and process, these rubric elements concern the use of data outside the organization, and restrictions on such use. 

  • Data Request: The data governance program has a documented data request policy and associated process for submitting, reviewing, approving or denying, and fulfilling data requests.
  • Data Release and Reporting: The data governance program has a documented data release policy and associated process for ensuring that data and data products from the system have been (1) validated by the appropriate members and (2) are created in accordance with reporting standards to ensure sufficient data privacy, quality, and consistency over time.
  • Data Privacy and Confidentiality: The data governance program has a documented data privacy and confidentiality policy and associated processes and training to ensure that all relevant federal and state privacy and confidentiality laws are followed by participating entities and external data requesters.
  • Data Security: The data governance program has a documented data security policy and associated protections to ensure that the data are securely transmitted and stored, and detailing the response to a data breach.
  • Data Destruction: The data governance program has a documented data destruction policy and associated processes to ensure it is complied with by participating entities and external data requesters.




This Checklist is based on the following Washington State processes, some of which are mandatory for state agencies, and common practices in the industry.

  • Records Inventory under RCW 40.14.040, managed by Washington State Archives
  • Application inventory managed by OCIO
  • ISO 15489 – implementing Enterprise content Management

Preliminary Investigation

Based on ISO 15489 State Archives guidance step 1

  • Identify and document key contributors to the inventory, including the following roles: Project Management, Legal & Public Disclosure, Records management, Business Process analysis, Information Technology, Communications (PIO), Training
  • Optionally, identify and record the business case for the inventory – what’s the value for the major groups involved? Why are we doing this?
  • Assess your electronic records management maturity.  Are any of the leading practices are readily apparent in your organization?

Business Process Assessment

Do a high level assessment of the key processes of each business unit within the organization, based on Archives and ISO step 2.  This is designed to capture the tools and systems that your teams use regularly, even if they don’t seem like IT. This work is usually done by the Business Process Analysis role of the inventory team identified in the Preliminary Investigation.

For each process or activity, record the following data points:

  • The business unit that is in charge of the process
  • How many people work on the process
  • What applications (or “software”, “programs” or “systems”) they use in working the process
  • What kinds of records (such as invoices, forms, queries, warrants, contracts, notices, etc.) they see in the process

Commitments Catalog

Document and review the Records and Legal requirements for the agency, based on ISO and Archives step 3.  This work is usually done by the “Records” and “Legal” roles of the inventory team identified in the preliminary investigation.

  • Consult Secretary of State’s Archives division for assistance, if needed
  • Consult the Attorney General’s office for assistance with public records, if needed
  • Identify and capture any commitments in your organization’s Open Data Plan, Risk Register or Data Governance strategy, if such exist

Systems (Applications) Inventory

Assess your organization’s systems and applications, based on ISO/Archives step 4, state Technology policy 112 and the annual “Application Inventory” and certification.  This work is usually done by the Information Technology role of the inventory team identified in the Preliminary Investigation.

  • Consult the OCIO for help, instructions, and previous reports to start from.
  • Compare the results of the Business Process analysis with the Systems Assessment, and identify processes or records that are not captured in a known application.

Initial Data Map

Produce your initial data “map” – it’s really a table of who uses what and when. This work is usually done by the Information Technology role on the inventory team identified at the beginning.

The map should address the following questions for each system, based on archives and OCIO guidance:

  • What are the names of the system?
  • Are there any data sharing agreements in the agency Contracts database that pertain to the system?
  • What happens to old data in the system? How is it disposed of?
  • Is the system (not the file) protected by encryption? 
  • State Archives advises (or requires) that files not use encrypted formats; the State CIO advises (or requires) that the computer equipment that holds state data use encryption.
  • What departments/positions access it?
  • What business processes does it support?
  • How often and how broadly is it used – how many users or uses per week?
  • Is it supported, aging, or near the end of their lifespan?
  • What other software tools or file formats does it depend on?
  • Who are primary IT/RM contacts for each department/application?
  • Who is/are the primary “stewards” or “custodians” for the data produced?
  • Is the system used by members of the public?  Other agencies? Contractors?

Develop a Work Plan

Develop a work plan for the coming year to confirm and expand your knowledge of your data assets, and to close gaps identified, based on ISO/archives step 5.

  • Use a Gantt chart ( ) to plan and stage the tasks needed to document data or records not associated with any known System or Application in the organization’s Application Inventory.
  • Use one or more of the following to gather data for validation or gap analysis
    • Employee Survey
    • Document analysis
    • Stakeholder interviews
    • Process diagramming, functional analysis, or LEAN methods
  • Explore automated tools for data and records discovery, such as:

Check progress

Assess your electronic records management maturity. 

  • Repeat the Leading Practices checklist again -- How many of the leading practices are evident in the work explored by the inventory team?
  • Update the work plan and team membership



Today, many organizations believe that the more data you have the more valuable it is. However, the over collection of personal information can dramatically increase the potential harm to individuals in case of a data breach. In addition, collecting unnecessary or indirect information that is loosely tied to a purpose is increasingly viewed as exceeding the scope of consent.

Data Minimization is a key privacy principle to respecting individual privacy and reducing risks associated with a data breach. Under this principle, only personal information that is directly relevant and necessary to a specified purpose is collected and kept for only as long as needed for that purpose.

Collection limitation: what information do I need?

  • Identify what type of personal information is required for a given process (e.g. birthdate as a mandatory field). Evaluate if this information should be mandatory, voluntary, or not collected at all (reducing risk).
  • Consider whether the requested personal information is necessary to complete the transaction or purpose of the collection.
    • Tip: Ask for personal information when needed, even if it creates a separate round of data collection. Oftentimes it can seem easier to collect more information upfront in case it is needed later. This is a common trap that leads to unnecessary and risky data collection.
  • If personal information is used as a unique identifier (such as a social security number), consider whether it is possible to use or create an alternate ID.
  • Ensure that individuals are aware of the types of information being collected and understand why that information is being collected.
    • Tip: For information whose purpose is not obvious, an individual should be aware why the information is being collected and how information will be used. For good privacy practice, do not simply list the types of data being collected in terms of service agreements or other fine print. Rather, describe the purpose at the point of collection.
  • Consider legal risks requirements for the collection and retention of personal information.
    • Tip: Certain types of personal information may trigger various legal obligations (such as health information) or unintended legal risks. For example, the collection of a birthdate could expose a website operator to the Federal Trade Commission’s Children's Online Privacy Protection Act (COPPA). Although a site may not be targeted at children, if a user indicates they are under 13 years old, COPPA obligations may still apply to the information collected.

Data inventory: what types of information do i have and where are they found

  • Identify which departments have data within the organization and who is responsible for the data.
  • Identify the types of data that the organization has and which may contain personal information. For example:
    • Financial data
    • Health information
    • System/device information
    • Emails, documents, photos, videos
    • Databases
  • Document where the information is stored. For example:
    • On-premise servers 
    • Cloud servers 
    • Backup storage drives
    • Desktops
    • Laptops
    • Remote offices
    • Employee-owned devices
    • Paper files
  • Map where data is shared from internally and to third-party organizations.
  • Consider how data can be recovered from the various storage locations and whether necessary data could be restored.

Data retention: what is the lifespan of my data

  • After identifying what types of information the organization stores, consider any legal retention requirements for particular types of data. For example, data related to:
    • Employment 
    • Medical / health services
    • Taxes 
    • Trade
  • Document retention policies for the various data types. For example, “retain email data daily for 90 days”, or “retain employment data every year-end for 5 years.”
  • For personal information that does not have a retention requirement, identify when and how that information is being deleted/purged.
    • Tip: Personal data should only be retained as long as needed for a specific purpose.
  • Investigate solutions for deleting personal information upon an individual’s request.
  • Establish periodic reviews of retained data.


  • Identify individuals or roles who are responsible for data collection and maintenance and train them on data minimization practices.
  • Identify what tools are used for privacy assessments, data mapping and data retention. For example:
    • Informally via emails or in-person communication
    • Spreadsheets
    • Internally developed system
    • Compliance software
    • External audits or consultants
  • List challenges to data minimization implementation. For example:
    • Lack of resources to complete data inventory
    • Low priority for the organization
    • Inability to maintain period reviews
  • Discuss challenges to improve privacy practices with the organization’s leadership or privacy officer.

Although not all organizations rely on data sharing as a core process to their business models, most organizations need to share some amount of personal information to operate efficiently. For example, data is often shared with third-parties who supply tools for HR processes. In many cases, employee personal information is entered and stored on the third party’s servers, where the use and protection of that information is out of the employer’s control. 

Whether data sharing is a key operation or passive transfer, organizations should determine if sharing of data is permitted, consider the privacy and compliance implications involved in data sharing, and ensure appropriate protections are in place for shared data.

Purpose: To share or not to share

  • Identify what is the purpose or objective of sharing data that contains personal information.
  • Consider whether the objective can be achieved without data sharing.
  • Consider whether the types of personal information being shared would be reasonably expected by individuals to whom the information relates.
    • Tip: Unreasonable or unexpected sharing of personal data could be considered an unfair or deceptive act. These practices are overseen by the Federal Trade Commission.
  • Ensure that the organization has the authority to share the data.
    • Tip: In some instances, an organization may be required to obtain consent from individuals. Without consent, some data sharing arrangements may violate contractual or regulatory obligations.
  • Identify what data will be shared, which organizations will be involved in the sharing arrangement, and who needs to be informed of the arrangement.

Agreements: Get commitments in writing

  • Agree on common retention periods for the data.
    • Tip: Be sure the data sharing arrangements meets or exceeds the privacy commitments originally made to individuals.
  • Specify the deletion or destruction processes and what will trigger erasure.
  • Include specific data security requirements.
    • Tip: Reasonable data security is a constantly evolving standard. It is good practice to include specific technical capabilities. This can be done by reference to a specific data security standard such as ISO or NIST, including an organization's security policies as an addendum to the agreement, or listing out specific data security practices.
  • Be sure data breach notifications from third parties will be provided promptly enough for the organization to be able to notify its own users.
  • Build in contractual limitations to who in the third-party organization can access the shared data and for what purposes.
    • Tip: The purposes for use by a third party shouldn’t exceed the scope of consent originally given by the individuals.

Security: Beyond contractual obligations

  • Obtain a copy of the third party’s data security policy. This policy should generally include commitments related to:
    • Network operations
    • Data storage
    • Data access
    • Data transmission and encryption
    • Retention
    • Audits and/or Standards
    • Data Breach and Incident Response
  • Identify which of the third party’s security practices are less stringent than the organization’s, and consider whether additional security requirements are needed.
  • When appropriate, conduct a site visit to the third-party organization to verify security practices.
    • Tip: More organizations are being held accountable for security failures of third parties in data sharing arrangements. Depending on the quantity and sensitivity of data being shared, due diligence may include a site visit to or audit of the location where the data will be processed or stored.
  • Know the third party’s mandatory disclosure requirements (e.g. court orders, warrants, contractual obligations, etc.), and consider whether any would be inconsistent with the organization’s policies.
  • Set a timeline for regular review or update to security requirements as a technology advances.
  • RecordsLeadingPractices-Responsibility
    • Someone in the agency has overall responsibility for managing and retaining records;
  • RecordsleadingPractices-Policies
    • Agency has written policies and procedures for managing and retaining records;
  • RecordsLeadingPractices-Tools
    • Agency has adequate software, hardware and physical storage for managing and retaining records;
  • RecordsLeadingPractices-Staff
    • Agency staff know how to manage and retain their records;
  • RecordsLeadingPractices-Retained
    • Agency keeps records for the minimum retention period listed in current approved records retention schedules;
  • RecordsLeadingPractices-knownlocations
    • Agency knows what records they have, where they are and their formats;
  • RecordsleadingPractices-organized
    • Agency keeps records organized to help with access, security and destruction/transfer;
  • RecordsLeadingPractices-Retention
    • Agency knows how long each type of record needs to be retained;
  • RecordsLeadingPractices-Destroyed
    • Agency destroys “Non-Archival” records and transfers “Archival” records to Washington State Archives at the end of the minimum retention period;
  • RecordsLeadingPractices-Disaster
    • Agency has plans and backups of records needed to resume critical operations in the event of a disaster.

Privacy and data security are huge concerns for consumers with today's extensive use of technology for acquisition and storage of information. The threat of personal information being misused is emerging in the growing DNA sequencing market where consumers are yearning to discover their roots and genetic origin. The privacy concern in this arena is that the consumer maybe giving the company rights to sell their sequenced DNA to data brokers, life insurance companies, etc. This checklist provides a roadmap of the industry and how to protect your DNA sequence from being bought and sold like a common commodity.

  • Understand the terms of sale and conditions of the company you are going to use.
    • Each company reserves ownership rights in your DNA samples, results, and reports.
    • Note: This means that whatever company you use has rights to reuse your DNA results etc. and you have little or no recourse.
  • Research the companies individually, while they do reserve rights in your DNA some will protect the sample more rigorously and will be more discriminating with future use.
    • Ex: My Heritage ® says they will only use the, "minimum amount necessary to provide the service..." Thus providing a high level of protection
    • Ex: 23 and Me ® will use your data more liberally for the stated purpose of improving their service. This is a more opaque contract that leaves the door open for the company to do a lot more with your information than say My Heritage.
  • Opt-in services
    • Some of the companies provide "opt-in" and "opt-out" options. If they do, read the terms and decide if you want to opt-in or out of these studies etc. This is a good way to further protect your information from unauthorized or unknown uses.
  • Consumer protections and pitfalls
    • The Genetic Information Nondiscrimination Act (GINA) protects this type of information from being used against you for health insurance purposes.
    • GINA does not protect a Life Insurance company from refusing to provide you with health insurance based on the results of your DNA sequencing.

Privacy by Design is a concept that privacy measures and considerations are made throughout the entire process / product development lifecycle. This approach helps to design more secure systems because privacy mechanisms are baked into the process as opposed to layered on top of a finished product built without privacy in mind. Privacy by Design features seven Foundation Principles:

  1. Proactive not Reactive; Preventative not Remedial
  2. Privacy as the Default Setting
  3. Privacy Embedded into Design
  4. Full Functionality - Positive-Sum, not Zero-Sum
  5. End-to-End Security - Full Lifecycle Protection
  6. Visibility and Transparency
  7. Respect for User Privacy - Keep it User-Centric

Recognizing privacy interests from the start can help reduces data security risks down the road as well as costs associated with remediation.

Project Scope

  • Describe the project, including objectives, users, programs, and any third-party components.
  • Create a data flow table. The table should show how data moves from one element of the project to the next, beginning with data collection to use to disclosures, if any.
  • Determine the sensitivity level of the data the project will incorporate.
  • Tip: Some privacy regulations will define what types of personal information should be considered highly sensitive or moderately sensitive.

Risk Assessment

  • Conduct a preliminary Privacy Impact Assessment (PIA). A preliminary PIA will ask whether the description of the project and its anticipated use of data meets general privacy principles.
  • Tip: If you know the project will be subjected to specific privacy regulations such as HIPAA, include those legal obligations in the PIA.
  • Tip: For projects that are further beyond the initial design phase, a full-blown PIA that considers additional data security mechanisms may be better at identifying areas for privacy improvements.
  • Note privacy advantages and risks when considering alternative approaches to a specific element or task of the project. This will help to discover serious versus minor risks, identify the appropriate level of security, and decide on cost-effective privacy measures.

Mitigation Methods

  • Review privacy risks and propose ways to mitigate the risks and any associated costs.
    • Tip: It may be helpful to categorize which risks are mandatory to address before the project proceeds.
  • Re-evaluate the project in light of the identified privacy considerations and necessary changes.
    • Tip: Sometimes an idea that seems novel may not be on the market because it is problematic with privacy concerns and regulations. It may be the case that the project isn't feasible or worthwhile if data cannot be used in a certain way that conflicts with privacy principles or regulations.
    • Tip: At the same time, Privacy by Design doesn’t mean that projects need to incorporate the most stringent protections. Rather, it is about including privacy measures that are appropriate for the project, and identifying those measures early on to make the project more feasible than trying to build security around an already developed product.
  • If possible, perform testing of implemented privacy measures to ensure they are proper solutions for the risks they are meant to address.
  • Identify how privacy issues will be monitored after the project is finished or throughout updates. This may include designating a privacy or compliance team to oversee or audit the project.
  • Document the policies, procedures and guidelines related to the use and privacy compliance of the end product.

A Privacy Impact Assessment (“PIA”) is a method for collecting and documenting detailed information collected in order to conduct an in-depth privacy review of a program or project. It asks questions about the collection, use, sharing, security and access controls for data that is gathered using a technology or program. It also requests information about policies, training and documentation that govern use of the technology. The PIA responses are used to determine privacy risks associated with a project and mitigations that may reduce some or all of those risks. In the interests of transparency about data collection and management, many Washington jurisdictions have committed to publishing all PIAs on an outward facing website for public access.

PIA preliminaries

As staff complete the document, they should keep the following in mind.

  • Responses to questions should be in the text or check boxes only, all other information (questions, descriptions, etc.) should NOT be edited by the department staff completing this document.
  • All content in this report will usually be available externally to the public. With this in mind, avoid using acronyms, slang, or other terms which may not be well-known to external audiences. Additionally, responses should be written using principally non-technical language to ensure they are accessible to audiences unfamiliar with the topic.

A PIA may be required in two circumstances.

  • Your project, technology, or other review has been flagged as having a high privacy risk
  • Your technology is required to complete a Surveillance Impact Report process. This is one deliverable that comprises the report.

PIA - Abstract

  • Capture a brief description (one paragraph) of the purpose and proposed use of the project/technology.
    • This 1-3 sentence explanation should include the name of the project/ technology/ program/ application/ pilot (hereinafter referred to as "project/technology"). It should also include a brief description of the project/technology and its function.
  • Explain the reason the project/technology is being created or updated and why the PIA is required.
    • This 1-3 sentence explanation should include the reasons that caused the project/technology to be identified as “privacy sensitive” in the Privacy Threshold Analysis form, such as the project/technology collection of personal information, or that the project/technology meets the criteria for surveillance.

PIA - Project

Provide an overview of the project or technology. The overview gives the context and background necessary to understand the purpose, mission and justification for the project / technology proposed

  • Describe the benefits of the project/technology.
  • Provide any data or research demonstrating anticipated benefits.
  • Describe the technology involved.
  • Describe how the project or use of technology relates to the organization's mission.
  • Who will be involved with the deployment and use of the project / technology?

PIA - Governance

Provide an outline of any rules that will govern the use of the project / technology. Please note: non-City entities are bound by restrictions specified in the Surveillance Ordinance and Privacy Principles and must provide written procedures for how the entity will comply with any restrictions identified.

  • Describe the processes that are required prior to each use, or access to/ of the project / technology, such as a notification, or check-in, check-out of equipment.
  • List the legal standards or conditions, if any, that must be met before the project / technology is used.
  • Describe the policies and training required of all personnel operating the project / technology, and who has access to ensure compliance with use and management policies.
  • Include links to all policies referenced.

PIA - Collection + Use

Information about the policies and practices around the collection and use of the data collected.

  • Provide details about what information is being collected from sources other than an individual, including other it systems, systems of record, commercial data aggregators, publicly available data and/or other city departments.
  • What safeguards are in place, for protecting data from unauthorized access (encryption, access control mechanisms, etc.) and to provide an audit trail (viewer logging, modification logging, etc.)?
  • What measures are in place to minimize inadvertent or improper collection of data?
  • How and when will the project / technology be deployed or used? By whom? Who will determine when the project / technology is deployed and used?
  • How often will the technology be in operation?
  • What is the permanence of the installation? Is it installed permanently or temporarily?
  • Is a physical object collecting data or images, visible to the public? What are the markings to indicate that it is in use? What signage is used to determine department ownership and contact information?
  • How will data that is collected be accessed and by whom?
  • If operated or used by another entity on behalf of the City, provide details about access, and applicable protocols. Please link memorandums of agreement, contracts, etc. that are applicable.
  • What are acceptable reasons for access to the equipment and/or data collected?

PIA - Data Storage

Information on how the data will be stored, retained and deleted

  • How will data be securely stored?
  • How will the owner allow for departmental and other entities, to audit for compliance with legal deletion requirements?
  • What measures will be used to destroy improperly collected data?
  • Which specific departmental unit or individual is responsible for ensuring compliance with data retention requirements?

PIA - Sharing

  • Which entity or entities inside and external to our organization will be data sharing partners?
  • Why is data sharing useful?
  • Are there any restrictions on external data use? If so, identify procedures and policies for ensuring compliance with these restrictions.
  • Explain how the project/technology checks the accuracy of the information collected. If accuracy is not checked, please explain why.
  • Describe any procedures that allow individuals to access their information and correct inaccurate or erroneous information.

PIA - Compliance

  • What specific legal authorities and/or agreements permit and define the collection of information by the project/technology?
  • Describe what privacy training is provided to users either generally or specifically relevant to the project/technology.
  • Given the specific data elements collected, describe the privacy risks identified and for each risk, explain how it was mitigated. Specific risks may be inherent in the sources or methods of collection, or the quality or quantity of information included.
  • Is there any aspect of the project/technology that might cause concern by giving the appearance to the public of privacy intrusion or misuse of personal information?
  • Examples might include a push of information out to individuals that is unexpected and appears to be intrusive, or an engagement with a third party to use information derived from the data collected, that is not explained in the initial notification.
  • Describe how the project/technology maintains a record of any disclosures outside of the department.
  • What auditing measures are in place to safeguard the information, and policies that pertain to them, as well as who has access to the audit data? Explain whether the project/technology conducts self-audits, third party audits or reviews.

Open data is the concept that some data should be freely available for everyone to use and republish. For companies who publish open data it is important to ensure the security and accuracy of the data before publication. Taking the necessary steps and investing in the proper security protections before the data is ever published will help to reduce current and future data security risks and costly remediation.

Identify a potential data offering

  • Convene or engage stakeholders such as: Data Steward, Requestor (if applicable), Open Data champion.
    • Make a record of the proposal, and a discussion of the business purpose
    • Assemble Technical data documentation to precisely identify and describe the content
    • Determine the business purpose to be met, and how publishing data will serve that purpose
    • Identify the data content needed to meet the purpose and the duration the data will be needed.

Assess the risk of publishing

  • It is important to involve one or more of the following individuals in this process. Transparency is crucial and keeping these individuals involved will help make the process faster and easier.
    • Data Steward- Not all companies will have a Data Steward. A data steward is a person in an organization that is responsible for utilizing an organization's data governance processes to ensure the fitness of the data elements-content and metadata.
    • Data Requestor- the requestor is a person who submit requests the IT organization. These could be incident request, service request, request for change, request for information etc.
    • Open Data Champion- an individual appointed who shall be accountable for maintaining their department's data catalog and ensuring that published data is refreshed on a regular basis.
    • Risk Management & Legal Services
    • IT
    • Communications
    • Performance Management
    • Note: while your organization may not have all of these individuals, you should still involve those that are present at the organization.
  • Assess whether you have the necessary resources and knowledge. Do you have:
    • Expertise/experts on data security laws
    • Expertise/experts on public records
    • Means of acquiring comprehensive subject matter advice
    • A data classification policy
    • A decision-making process
  • Once you have assessed all of the necessary factors make a record of the final recommendation

Assess the technical feasibility of publishing

  • Discuss these issues with the relevant parties: Data Steward, IT, or Communications department. Transparency and intra-organization communication is vital.
  • Identify resources / knowledge needed
    • Feasibility criteria (size, complexity, impact of the data)
    • Technical data documentation
    • Expertise on data management
    • A decision-making process
  • Determine how the proposed data publication would be executed and analyze the technical feasibility of doing so.
  • Make a record of the final recommendation

Establish a technical support plan for the data

  • Discuss these issues with the relevant parties: Data Steward, IT, or Communications department. Transparency and intra-organization communication is vital.
  • Assemble a record and resources including:
    • A record of the proposal, including a discussion of the business purpose
    • Technical data documentation
    • Persons with expertise on data management
    • Agreements to roles and responsibilities
    • Agreements to commit to roles and responsibilities
    • Documented support plan for each data set
    • Definition of the data content’s refresh schedule and archive schedules
  • Determine what support is needed to keep the data correct and relevant,
  • Design a support plan

Generate the data set for original systems

  • The Data Steward provides:
    • prototype or beta version
    • dataset format specifications
  • IT staff will:
    • apply documented technical procedures
    • deploy dataset with agency infrastructure resources, e.g. open data portal, agency website, community API's

When generating metadata:

  • The IT staff shall provide technical procedures to follow and a simple log of actions to deploy
  • The Data Steward will apply its expertise on metadata, and make sure to follow state metadata standards
  • The Data Steward then produces metadata file

Publishing the data offering and metadata

  • The Data Steward must review the dataset and approve the publication
  • Either the IT or Data Steward may expose the dataset to the public
  • Notify the relevant stakeholders, maintaining open communication and transparency throughout this process will ensure it runs smoother and faster: Data Steward, Data Requestor (if applicable), IT, Communications, and/or State Open Data Champion.
  • Once the data set is published the company shall set date and schedule for refresh and review the data publication.

Reviewing and refreshing data publications.

  • Maintain transparency and communications with those relevant personnel within the organization: Data Steward, Data Requestor (if applicable), Open Data Coordinator and/or Communications
  • Review the record or project file which should include:
    • A record of the proposal, including a discussion of the business purpose
    • Documented support plan for each data set
    • Current technical data documentation
    • Prior technical feasibility decision
    • Prior risk assessment decision
    • Documented technical procedures
    • Communication plan
    • A decision-making process
    • A record of the final recommendation
  • Assess the relevance and accuracy of the data set,
  • Depending on the relevance or accuracy decide to leave as is, refresh, or remove the data as necessary

Measure the performance and report on status.

  • Continue to engage the relevant personnel: Data Steward, Data Requestor, Open Data Coordinator, and/or Communications.
  • Quantify and assess the benefits of the data publication, using:
    • Metrics for measuring usage
    • Feedback mechanism for users
    • Request mechanism for users
    • Advise State Open Data champion

So You've Been Hacked - How to Recover?

This checklist is intended to help state agencies deal with cybersecurity incidents.  Private citizens will likely find “So You Think You’ve Been Hacked” more useful.   Not all cyber incidents result in Data Breach; if a Data Breach is suspected, agencies should also use the “Data Breach Response” checklist.

Establish the facts

  • Consider: Who is reporting the problem? How did they become aware?
  • Observe: What do we know so far about what happened?
    • What networks/systems are affected?
    • What data/information was compromised (e.g., stolen,deleted, altered)?
  • Record: When did the incident  occur?
    • When did we find out about it?
    • When did we begin to do something about it?
    • When will we know the full scope of the problem?
    • When do we estimate that the problem will be remediated?
    • Where did the incident occur (what office, activity, locale, etc.)?
    • How much do we know with certainty about how the incident occurred? Do we know the source of the attack?
  • Plan: How will we stay informed of efforts to remediate the breach and restore normal service?

Mobilize a response

You're not alone in responding to an incident -- the state has multiple expert resources.  Consider the following in reaching out to them:

  • Who has the lead in directing operational response efforts? What role will your office play?
  • What other actions do your breach notification laws require?
  • What are the legal implications of the incident?
  • Have you notified your AAG, DES ORM and the Office of CyberSecurity?
  • Who else should be notified at this point (e.g., citizens, business and industry, other state, local, federal officials, etc.)?
  • Has law enforcement been notified?
  • What expertise is on hand to work the problem? What additional help do you need? Who will provide it?
  • What measures are needed to secure the networks/systems from further exploitation?
  • What additional steps are needed to secure data holdings?
  • How will the remediation efforts to limit/repair the damage and restore normal services be prioritized?
  • What special notifications should be prepared for victims?

Communicate what you know

Here, as elsewhere, bad news does not get better with age, but remember the general rule that the first report is always wrong.

  • Release your initial public statement as soon as you have a reasonable command of the problem and can explain what you are doing about it.
  • Describe what you know so far about what happened and what is being done to correct it.
  • Be prepared to explain the pre-existing cybersecurity posture and the measures that were in place to prevent events of this kind.
  • Be prepared to explain the steps you will take to prevent future unauthorized intrusions. Start with basic cyber hygiene and the Critical Security Controls.
  • Establish a regular cadence of updates for victims, media, and other stakeholders- including your own workforce.


Data security
Data breach
Security breach

Breaches are becoming more common because of the collection and storage of mass amounts of data. But how do you know if a breach occurred? What type of information is important and what actually constitutes a breach. This checklist provides an overview of what to look for and how to assess whether a breach occurred. Remember, you should always conduct a debriefing whenever you think a breach occurred.

  • Describe incident and nature of confidential information that was potentially compromised
  • Deduce whether the information was secured* (was the information encrypted or otherwise unusable, unreadable, or indecipherable to an unauthorized individual?)
    • Note: Secured means encrypted in a manner that meets or exceeds the National institute of Standards and Technology (NIST) standard or is otherwise modified so that the Personal Information (PI) is rendered unreadable, unstable, or undecipherable by an unauthorized person. If you do not know if the information was secured by NIST standards, contact your Administration’s IT Security Administrator.
  • Determine whether the information is personal information?
    • Note: PI means an individual’s first name or first initial and last name in a combination with any one or more of the following: Social security number; Driver’s license number or Washington identification card number; or Full account number, credit or debit card number or any required security code, access code, or password that would permit access to an individual’s financial account.
    • If No, then notification is NOT required. Further response and completion of risk assessment is optional with program. End process and conduct debriefing.
    • If Yes, please continue with the process below.
  • Determine to whom the disclosure of Personal information was made (i.e. was it made to an authorized person, unauthorized person etc.) and whether that person would not reasonably be able to retain the information?
    • If made to an authorized person, who could not reasonably be able to retain the information, then not a breach, tender an explanation. End process and conduct debriefing.
    • If Unknown: Continue with process below.
    • If not made to an authorized person or the person could reasonably retain the information, then continue with process below
  • Determine whether the acquisition, access or use of the PI, was used by or for any or all of the factors below
    • Factors:
      • By an employee or contractor to an employee or contractor;
      • Unintentional;
      • Made in good faith and within the scope of authority; AND
      • With no further unauthorized use or disclosure.
    • If you said yes to all four of the factors then the incident is not a breach. You do not need to continue with the assessment but must conduct a debriefing.
    • If you said no to any of the factors then you must continue to assess the extent of the breach
  • Determine whether disclosure of the PI was: (Check all that apply):
    • Factors:
      • Inadvertent;
      • By an employee or contractor who is authorized to access PI;
      • To another employee or contractor authorized to access PI; AND
      • With no further unauthorized use or disclosure
    • By affirmatively answering all four of the above factors then a breach did NOT occur. You do not need to continue with the risk assessment but must conduct a debriefing.
    • No, if all four factors did not apply then please use Risk Assessment Checklist to evaluate the risk incurred by the breach.

Once you have discovered a breach occurred what do you do? Remember: the acquisition, access, use, or disclosure of PI in a manner not permitted by law is an apparent breach unless the agency can demonstrate that it is not reasonable to believe that the PI has been compromised based on a risk assessment of at least the factors below.

Determine the nature and extent of PI involved, including types of identifiers and ability to identify individuals:

  • Low: The information is publicly available information that is lawfully made available to the public from federal, state, or local government records
  • Moderate: The information is comprised of demographic or administrative information that could be used to identify individuals but not sensitive or specially protected
    • Ex: The information lists names with services that does not involve other PI or is not related to sensitive specially protected services such as mental health or chemical dependency etc.
  • High: The information includes elements that could be used for identity theft, records that are highly sensitive or personal, and are protected by heightened confidentiality laws.
    • Ex: Information that identifies names or other unique identifiers tied with social security numbers, driver’s license numbers, financial account numbers with passwords, mental health or chemical dependency treatment records, and IRS and social security records.

Determine the nature of the person who acquired, accessed, used or received the PI:

  • Low: Limited or no risk of re-disclosure of information by recipient.
    • Ex: Employee of another agency or trusted contractor: recipient required by law to maintain confidentiality such as attorney/client privilege or law enforcement; recipient subject to confidentiality laws and confirmed did not access data or returned data intact and did not retain copy.
  • Moderate: Moderate or unknown risk of disclosure.
    • Ex: when information is lost or missing and may not have been accessed; it is unclear or unknown whether recipient accessed or retained data; recipient returned information; and recipient was not subject to confidentiality law but acting in good faith.
  • High: There is a severe risk of disclosure and recipient likely to re-disclosure, sell, or transfer data or is known to have used PI for malicious purposes.
    • Ex: Acquisition was because of a criminal act including theft or hacking or information was obtained by a person with retaliatory motives.

Risk: Determine whether PI was actually accessed or acquired or viewed by unauthorized individual:

  • Low: No proof of access or acquisition of PI. Would be difficult or unable for individual to access personal information without sophisticated or extreme measures and individual had limited opportunity or ability to do so, or able to demonstrate lack of access through technical assessment.
  • Moderate: Unknown whether individual acquired access to PI or whether known individual acquired PI in a manner that could be replicated. Technical assessment of access shows limited access or is inconclusive. The means to access data is commonly known or available.
  • High: It is known or reported that access to PI was acquired, used, sold, or further disclosed for malicious purposes.

Take steps to mitigate the results of the breach

Ex: confirmed confidential information sent to the wrong recipient was returned or destroyed or policies and procedures were modified as a result of incident.

  • List a brief description of mitigation steps, person/entity responsible for breach, and target or date of completion.
  • After implementing mitigation steps, re-assess the remaining risk to personal information:
    • Low: All corrective actions have been taken and risks of future occurrences has been removed or reduced to acceptable level.
    • Moderate: some corrective actions has been taken but other reasonable steps cannot be implemented due to cost or other factors.
    • High: significant risk of continuing compromise of PI remains despite mitigation.

Rate your Risk

For each Risk Assessment Questions above create a chart and enter your risk rating (e.g. low, moderate, high).

  • There are 4 categories you need to assess and give a risk rating
    1. Nature and extent of PI
    2. Unauthorized persons acquiring PI
    3. Risk whether PI was accessed or acquired
    4. Impact on risk of compromise mitigation steps
  • Sum your risk ratings
  • Consider other possible factors that could impact your risk rating.

Determine whether the unauthorized acquisition, access, use, or disclosure of PI compromised the security or privacy of Personal Health information (PHI)

  • Based on the above factors determine if there is a low probability of compromise of PI. That is, it is not reasonable to believe that PI was comprised and it is not reasonably likely to subject individuals to risk of harm—then not a breach under RCW 42.56.590. End process and conduct debriefing.
  • If there is more than a low probability of compromise of Personal information then a breach has occurred. Proceed with notification steps required by RCW 42.56.590.

Record your findings and provide an explanation.

Controls on Social Media and Advertising

LinkedIn has a large amount of information about its users professional lives, and has a recent, readable privacy policy:

Privacy Policy -- what they know about you and what they do with that info

Summary of changes -- recent changes in layman's terms

User Agreement -- what you need to know about them, what they allow, etc.

Blog describing changes in order to comply with Europe's GDPR

Slack, the work/chat tool beloved by small and distributed technology teams, has updated its privacy policy to comply with European privacy law

Privacy policy  covers what they collect and share about you

User Terms   covers what you should know about them, like what kinds of uses are acceptable on the site

Yahoo, one of the giants of the early internet, has a prominent privacy policy
They have been bought out by Verizon, and acquisitions sometimes change privacy policies.

Here's a quick list of privacy links and tools for Facebook

Website Page Link
Facebook Explanations
Facebook Ad Controls

Apple has a few privacy pages:

A general explanation of how they do privacy
The privacy policy for their website

Microsoft has a few privacy-related pages and programs

General description of privacy at the company:
Privacy Statement for their website