Which Action Is a Breach of Test Security

If you’re a test coordinator or school staff member, you shouldn’t rely on vague warnings about “security.” You need the practical answer to the exact question: which action is a breach of test security—and what you should do in the first few minutes when something goes wrong.

What “breach of test security” means (integrity and effectiveness)

A breach of test security is an action that undermines the integrity of the assessment and/or inhibits the effectiveness of the assessment from producing its intended results.

In plain language: the test isn’t still doing the job it was meant to do. Something may have happened that affects:

• whether students have the same, fair opportunity to show what they know, and/or
• whether the test results are valid and trustworthy.

A key point: test security isn’t only about stealing test items. It’s also about administration choices that can change what students experience during the test.

quick decision rule

Ask one fast question: Would this make the results less reliable or less comparable across students?

If yes, you’re likely dealing with a “breach” or something very close to it.

Which action is a breach of test security? (common examples from test security guidance)

Here are common actions that SERP snippets and training-style guidance tend to flag, because they can affect student performance or create access to secure content.

Allowing restricted devices (example: smartphones)

One example that shows up repeatedly: allowing students to bring smartphones into the testing area.

This isn’t just a “minor rule break.” It can let students:

• look up information,
• get help in real time, or
• communicate answers.

Any of these outcomes can seriously harm the integrity of the assessment.

Changing directions or explaining content in a way that affects responses

Another example is when staff deviate from approved test directions—for instance, by rephrasing, explaining, or adding guidance in a way that wasn’t intended.

Even if the goal is to help, extra explanation can:

• hint at what students should look for,
• change how a question is understood, or
• give some students a benefit other students don’t get.

Deviating from secure administration expectations

“Deviation” is another big trigger in the snippets. If the process doesn’t match what was expected during test administration, it can be treated as serious because it can affect how valid results are.

If you’re thinking, “But we followed the spirit of the test,” pause and check the actual administration requirements. If what happened departs from secure expectations, handle it seriously.

What is a test security incident vs a breach?

This is where the terms can get confusing, so here’s the distinction.

• A breach of test security is tied to integrity and effectiveness. The action harms the test’s ability to produce meaningful, valid results.
• A test security incident is tied to a deviation that must be reported so officials can protect the validity of the assessment results.

The key takeaway: Any deviation in test administration must be reported as a test security incident. Even if you aren’t sure yet how serious it is, reporting helps the process catch the risk early.

When you’re unsure, treat it as an incident

If something doesn’t match secure administration expectations, report it as a test security incident. That prevents the school from trying to handle it informally when documentation and containment are needed.

What is an example of a security breach?

Think of a security breach as a clear integrity hit. One example mentioned in the snippets is:

• Allowing students to bring smartphones to testing.

That threatens integrity because it creates a path for outside help during the assessment.

Another breach pathway is content theft or access. For example, anything that leads students (or others) to have access to questions or answers before they should. If secure content is compromised, the assessment can’t accurately measure what students know under test conditions.

What actions are considered serious testing violations?

SERP snippets point to the idea that serious security problems—or other test irregularities—can lead to consequences for staff. This includes actions that:

• violate test security rules, or
• create irregularities that affect how testing is administered.

In practice, serious testing violations are the kinds of actions that make it more likely the results can’t be trusted.

Examples to keep top-of-mind

Even without listing every policy detail, the snippets emphasize a few categories:

• device rule violations (like allowing smartphones)
• administration deviations (anything that changes the test experience in a way that conflicts with approved procedures)
• confidentiality breaks (anything that weakens the requirement that test materials must be kept confidential)

Also note: violating test security—or creating major irregularities—can lead to breach testing and corrective action against a staff member.

What is considered a procedural testing irregularity (and what isn’t secure test materials)?

A procedural testing irregularity is usually about the *process*—a mismatch in how testing is run—rather than outright theft of content.

If the administration doesn’t follow the required process, it can be a procedural irregularity. And per the snippets, deviations must be reported as a test security incident to protect the validity of results.

What isn’t “secure test materials” (common sense boundaries)

You also asked what counts as secure materials. While the snippets don’t provide a full inventory, the basic idea is clear:

• Secure test materials must be kept confidential.
• Anything that undermines that confidentiality (sharing, copying, or exposing content) is serious.

If you’re unsure whether something counts as secure, treat it as if it does. Ask the test coordinator right away rather than deciding on your own.

Procedural irregularity vs. confidentiality breach

• Procedural irregularity: the test process didn’t follow the required steps.
• Confidentiality break: secure materials weren’t kept confidential.

Both should be taken seriously, and both require reporting when they involve deviations.

Immediate steps when a security breach happens

When you realize something may be wrong, the goal is containment. The snippets point to immediate actions that limit the damage while the situation gets handled.

Use this as a first-response checklist, even if you’re not 100% sure it’s a breach yet:

Immediate response checklist (contain and protect)

1. Stop testing temporarily if you believe test security has been compromised or a serious deviation occurred.
2. Identify and follow your applicable test security policies immediately. Use the guidance that covers your situation.
3. Replace compromised test content if the issue involves exposed or affected materials.
4. Confiscate compromised materials as needed (for example, anything that should not have been exposed to students).
5. Prevent further access—get everyone back to secure conditions while you document what happened.

Even if the issue turns out less severe than you first feared, stopping early helps protect the integrity and effectiveness of the test.

Reporting and documentation: who to inform and when

The snippets emphasize one expectation clearly: violations of test security or other test irregularities can result in breach testing and corrective action. Reporting isn’t about blame. It’s about protecting assessment results and keeping the process correct.

What to report, and when

• Report any deviation in test administration as a test security incident to support the validity of assessment results.
• Report breaches or suspected breaches immediately so containment steps can happen while the information is still fresh.

What to document

Write down what you can remember while it’s happening, including:

• what action occurred,
• when it happened (time matters),
• who was present,
• what materials were involved, and
• what steps you took (like stopping testing or confiscating materials).

Keep your notes factual. Don’t guess (for example, don’t assume “it probably didn’t matter”). If you acted, record what you did.

Who to inform

Your district or state chain of command will guide who to contact, but the “who” usually includes:

• your test coordinator,
• the school/district point person for testing incidents, and
• any required higher-level staff under your test security policy.

If you aren’t sure, report first to the person responsible for test security in your building, then follow their instructions.

Preparing the school before test day to prevent violations

Most test security problems aren’t caused by bad intentions. They happen because people aren’t clear on what counts as secure, or because the day gets busy.

Here’s a practical way to prepare so you reduce procedural testing irregularities and security violations.

Staff prep checklist (before students walk in)

• Review device expectations clearly with all staff. If phones aren’t allowed, say it plainly and consistently.
• Practice the approved direction approach. Remind staff not to add explanations that change how students interpret questions.
• Reinforce confidentiality: test materials must be kept confidential. Don’t share secure content with other staff, even “just to help another teacher.”
• Clarify the reporting rule: if there’s a deviation, it’s a test security incident that must be reported.
• Make the first-response steps clear: stop testing temporarily when needed, replace compromised content, and confiscate compromised materials.

If your team follows these steps, you’ll be ready for the “which action is a breach of test security” moment before it becomes a crisis. Use the breach-vs-incident checklist in your test-day plan, and walk your staff through what to do immediately if things start to go off track.