Skip Navigation

Chapter 8—Data Security

Whether or not an education agency has an LDS, data need to be secured to prevent unauthorized access and tampering. However, the collection, maintenance, and dissemination of student-level data via an LDS and other source systems increases the importance of data security. While many districts have long stored some personally identifiable information, states take on a new responsibility when they begin to manage personally identifiable, student-level data.

The Forum has more detailed information...


...about data security issues:

Security measures should keep sensitive data out of the wrong hands, while allowing maximum accessibility to users. An LDS contains sensitive data that can be compromised and used to expose restricted personal information, thereby violating privacy (Houde 2008). Protections must allow access to authorized users, while barring others from seeing or manipulating the data.

Know your data

Ownership model of data security

Within a data governance structure, ultimate responsibility for each of the agency’s data elements should be assigned to a single data steward (see chapters 1, 2, and 3). These stewards should work with the security team to determine the sensitivity of, and appropriate level of security for, every data element. Together, they may

  • classify each item’s level of confidentiality (e.g., public or restricted);and
  • identify the user groups, by characteristics such as job function or “need to know,” that should be granted access to each element.
As discussed in chapter 3, data stewards should also be the point of contact for requests of data they manage, and may authorize data sharing in response to those requests.

The first step in securing an education agency’s data is developing a clear view of its information “landscape.”

  • Determine what the agency has. Take an inventory of all of the data the agency collects and maintains.
  • Locate all the data. Document where the data are stored, including servers, individual computers, filing cabinets, and other media such as CDs and storage devices.
  • Document the “ownership” of each data element. Each data element should be the responsibility of a single data steward, who should be clearly identified.
  • Determine the sensitivity of each data element the agency manages based on privacy requirements under state and federal laws. Document the risks associated with exposure of sensitive information and/or assign a risk level to each element, perhaps through a simple rating scale.
  • Document who has access to what data, including internal staff, contractors, vendors, and external users. Note who can do what with the data (e.g., manipulate vs. view) and record all the ways these authorized users can access the data.
  • Determine and document how long various users will be allowed to access data and ensure access is denied once it is no longer appropriate. For example, agencies must diligently end or adjust staff access to data when they change positions or leave the agency. Also, states or districts (or school policymakers) must determine if teachers will be allowed to access personally identifiable information on their former students (some agencies update access by enrollment annually, while others grant teachers broad access to their former students’ information for a year or more, even into postsecondary).
  • Document data sources. From what source systems do your data originate? Who sends them?
  • Document data recipients. These may include federal agency departments, postsecondary institutions, research organizations, and all others who receive the data.
  • Document how data are transmitted. Data might be transmitted electronically, mailed on paper, etc.

Role-based data access

Users should have easy access to the data in an LDS, and standardized reports showing aggregate data and analysis results should be publicly available. Additionally, for ad-hoc querying and analysis, the general public may be given access to aggregate statistics and to non-identifiable individual student records. For personally identifiable information, users should be granted varying levels of access depending on their role, needs, and responsibilities. For instance, through an online application, users could gain access to permitted information by signing on with their individual username and password. A student’s record may be made available to that student, as well as to his or her parents or guardians, current teachers, counselors, school, district administrators, etc. However, the specific information shared may vary depending on the user’s identity; for example, only parents might be allowed to see a student’s lunchroom account balance. Researchers with appropriate contracts and permission may also be granted access to some personally identifiable data.

The Data Policy Committee or Data Governance Committee should document accessibility by user roles, as well as for what purposes the data can be used. These specifications should be granular enough to detail the rights of each type of user, allowing access to the information each is entitled to, but no more. Also, while access rights may be determined at the state level, some software programs allow delegation of access rights to occur at the local level. In other words, the application allows “delegated” district administrators to grant certain users access to sensitive information, if they deem such access appropriate.

While some education agencies run multiple software systems to access separate databases or data sets, others implement “single sign-on” systems to manage user identity and streamline access. Rather than assigning each user a different password and username for each data system, these agencies maintain a single username and password for each user and grant appropriate access across applications. Each user's access rights can be tailored based on his or her specific need for the data in each system.

Keep Only the Data Your Stakeholders Need

The more data an agency has, the more it must secure. Although stakeholders may demand a wide range of information, each agency should consider disposing or securely archiving any data deemed unnecessary, especially if they contain personally identifiable information. In this stage of the life cycle of information (see chapter 1 of Book Two: Planning and Developing an LDS), data should be destroyed in a manner consistent with their sensitivity.

  • Completely remove information (“wipe”) from old computers and storage devices before disposing of them; and shred, burn, or pulverize unnecessary paper records. Remote and onsite staff should follow the same procedures.
  • Going forward, collect only the information required to meet business and stakeholder needs.
  • Create a record-retention policy that details what information should be stored by the agency, how it should be secured, how long it should be kept, and how it should be destroyed once it is no longer needed. Agencies may set up a formal review process to assess data’s value and authorize disposal.

Secure the Data


Authentication is the verification of a user’s identity through means such as the submission of a unique password and/or other personal information. Authorization is the mechanism by which that authenticated user is granted access rights (e.g., the right to view data of varying degrees of sensitivity, or the right to manipulate data in addition to viewing them).

Agencies need to stay on their guard, identifying vulnerabilities and adapting to ever-changing security threats. Threats may come from within the organization or outside agency walls. The Internet, for instance, increases the risk to student privacy as individuals from the local education community or from across the globe can hack into data systems to change test scores, unleash viruses, or just wreak general havoc.

  • Establish a group or office specifically focused on security issues, perhaps creating an enterprise-wide security plan; and implement security strategies to manage data access and use.
  • Assign a security officer to lead this office. This staff member should be well-versed in all relevant privacy laws, and with the technology and business processes that facilitate compliance. The security officer may coordinate the agency’s security plan (authentication, intrusion detection, etc.) and must ensure that all staff are appropriately trained to protect the agency’s data.
  • Store data in a secure location accessible only to authorized personnel, and lock when not in use. This would include all sensitive information contained on servers, computers, media such as CDs, or on paper.
  • Automatically encrypt hard drives and use only password-protected thumb drives for transferring sensitive data (Houde et al. 2007).
  • Set access controls to the network and review them periodically. A user’s identity should be authenticated with a complex password, pass phrase, or other personal information.
  • Based on the level of access determined by staff (e.g. data stewards) and implemented through technology, each particular user should only be given access to authorized information.
  • Use intrusion-detection systems to identify suspicious access to the network.
  • Establish and utilize infrastructure components such as firewalls, backups, and antivirus and antispyware software (EIMAC 2008).
  • Protect data while they are moving (“in motion”) between data systems or to data users. For instance, student-level data might be encrypted before they are fed from a source system into the LDS, or from the state agency’s LDS back to a district.
  • To help keep private data from getting into the wrong hands, convene a Data Request Review Board (see chapter 3) to establish a clear process for handling data requests in an orderly and consistent fashion.
  • Create a contingency plan to facilitate a quick and appropriate response in the event data security is threatened or breached. This plan should specifically describe responses to a range of scenarios. For instance, how will the agency respond to network intrusion, a stolen laptop, or wrongful dissemination of sensitive information? Whom will you notify—law enforcement, staff, the individuals whose personal data have been compromised, the public, etc.—and should you use the phone, email, or other means of communication? How will damage to the system be controlled? How will the impact of the breach be assessed?


Even with a solid security plan, agency data will not be secure without proper implementation. All staff, not just IT, should understand the sensitivity of the records and the vulnerabilities of the system, and security should be a priority in everyone’s daily routine. Improving agency security therefore involves a certain degree of culture change.

Disaster preparedness

Natural and manmade disasters can severely disrupt educational activities, displacing students and interrupting services including data collection, maintenance, and use of data. LDSs, which may consolidate a wide range of data and data processes, are likely to be necessary for carrying out day-to-day business (“mission critical”). Moreover, when disaster strikes, these systems are vital to mitigating the effects of the crisis. For instance, the LDS can be used for enrolling displaced students in the appropriate grades, courses, and programs; meeting accountability requirements; and efficiently allocating funding. Agencies should carefully plan for destructive or disruptive events, including physically safeguarding the system, designing the system architecture to facilitate displaced student tracking (e.g., including data elements such as displacement identifiers and event descriptors), and creating policies for tracking students and exchanging data after a crisis.

The implementation of a state-level LDS offers several clear advantages in a crisis. For example, consolidating agency data into a single data store will facilitate preparations for a disaster, as the need to modify and coordinate a multitude of silo systems would be limited. During and after a crisis, the efficient exchange of high-quality, student-level data that are verified by centralized procedures and marked by individual identifiers via an LDS may help in many ways. For instance, administrators can use the data to efficiently and precisely target resources, provide displaced students with the proper services, and pass the scrutiny of federal data audits. Aggregate counts, on the other hand, may be inaccurate as they often contain duplicate counts. They may also be untimely as they take more time to produce, leading to slow and inefficient distribution of resources and a haphazard provision of services. Finally, states with an LDS may be able to ease the reporting burden of districts needing federal aid, as they may be able to deal directly with federal agencies on school districts’ behalf.

(National Forum on Education Statistics 2010)

Additional resources:

Disaster preparedness

Train and Inform Data Handlers

The Forum has more detailed information...


...about data ethics:

With an LDS, more staff members will gain access to sensitive student-level data. As access to data expands, so must security and confidentiality training to avoid unlawful data sharing or use. Some best practices follow.

  • Establish a training plan that tailors instruction to staff with different levels of access to sensitive data, giving those with more access more rigorous training. Training may also be tailored to specific groups of data users based on job functions.
  • Monitor the access granted to staff and provide additional training as needed.
  • Train and retrain staff and contractors periodically on the proper and ethical handling of sensitive data. This training should be completed before access to sensitive data is granted.
  • Hold staff accountable for failures to adhere to the agency’s security procedures and confidentiality policies.
  • Require employees and contractors to sign nondisclosure agreements.
  • Require researchers to sign memoranda of understanding (MOU) that detail privacy and security requirements.
  • Establish a means for communicating security issues to staff, perhaps via a security website, email newsletters, or meeting updates from security staff; communications should be both periodic and impromptu as issues surface.
  • Specify security requirements in requests for proposals (see chapter 14 of Book Two: Planning and Developing an LDS) and assess prospective vendors’ security practices or software specifications; this will help ensure the service provider or product can, in fact, meet the agency’s security needs.


LDS Lore: Identity theft in the printer room

At the school district office, Margaret typed in her password and accessed the teacher information system. She found the data she needed and sent it to the printer. The phone rang—Sally was calling about lunch. Starving, Margaret grabbed her coat and headed out for a burrito. Meanwhile, at the printer, Bonnie lifted a stack of unclaimed paper from the tray and set it on the table. She waited for her job to collate, snatched it, and left the room. After lunch, Margaret was extremely busy as one meeting flowed into another until it was time to make the commute home. Before close of business, Chris, the district's data governance coordinator, was making his rounds and noticed the pile of papers on the table. He picked them up, quickly realized what they were, and raced back to his office.

Meanwhile, Richard, the new janitor, was buttoning up his uniform. He'd heard that staff at the district office sometimes leave pretty valuable information lying around (the kind he'd read about in that non-disclosure agreement he'd signed) and he was looking forward to getting his hands on some. Later, at the office, he steered the vacuum around the desks, down the empty halls, and into the printer room, keeping his eyes peeled. He checked the recycling bins, garbage cans, table tops, looking everywhere for names, Social Security numbers, dates of birth— the good stuff that he could turn into cash. But even though he cleaned the place from wall to wall, nothing turned up. Better luck tomorrow night, he told himself before turning off the lights.

The following morning, Sally opened her email to find a message from Chris calling a mandatory meeting for all data stewards. The subject: Safeguarding sensitive data. A second email came from the district's security officer announcing a new round of training on data security. Just then, it all came back to Sally: the print job...the Mexican food...the meetings. Sally thought, as she rushed to the meeting, "I hope I didn't cause any damage."