Maryland School Cybersecurity Plan

Maryland local school systems have a concrete cybersecurity planning deadline: the first certification is due on or before June 30, 2027. But treating that date as the finish line creates the wrong project. A school system still needs accountable ownership, a controlled assessment scope, validated evidence, corrective-action testing, and a way to stay ready for the next assessment.

The Maryland School System Cybersecurity Certification plan is built around that operating reality. Its 38 task items sit within nine phases. Rather than moving directly from assessment to a submission package, the structure carries the work into recurring monitoring and a two-year reassessment cycle.

For the CIO, cybersecurity leader, compliance leader, or program manager coordinating this work, the practical distinction is straightforward: certification is one point in an assurance cycle. It is not a document exercise that can be completed and put away.

What Maryland's new requirement changes for local school systems

Maryland Chapter 34, House Bill 957 took effect July 1, 2026. It requires each local school system to designate a local point of contact for cybersecurity-related communications and notify the State Chief Information Security Officer of that designation and later updates.

Beginning in 2027, each local school system must comply with State minimum cybersecurity standards and conduct a cybersecurity maturity assessment every two years. The first certification is due on or before June 30, 2027. After that, certification is due each June 30 every two years. The statute also directs the Office of Security Management to review State minimum cybersecurity standards annually and update them if necessary.

The law establishes the trigger and timing. It does not make a charter, traceability matrix, monthly evidence routine, quarterly review, or board dashboard a universal statutory requirement. Those are planning choices in this template, intended to make certification work governable and repeatable.

The plan at a glance: 9 phases, 38 work items, one recurring cycle

The nine-phase delivery structure groups the work into five practical moves. The plan assigns task ownership across eight roles: Compliance, PM, Operations, IT, Legal, QA, Security, and Training. These are archetype roles, not a requirement that every school system create eight separate positions.

The important design choice is the final row. Two full phases begin after certification submission. That keeps evidence, oversight, and reassessment preparation from becoming cleanup work that starts only when the next deadline becomes urgent.

1. Start by making scope and ownership defensible

The first phase begins with the statutory point of contact, then adds a certification charter, a board reporting cadence, and a management review routine. The first item establishes a required communication owner. The remaining items are plan design choices that create a decision path when scope questions, assessment findings, or remediation tradeoffs arise.

The next phase creates a controlled scope baseline before standards mapping begins. It covers schools, operations, systems, data, service providers, and applicability assumptions. This is a recommended planning pattern, not a statutory checklist. Its purpose is to prevent a common assessment failure: collecting evidence for remembered systems while overlooking a school-level process, shared service, or vendor dependency that affects the operating environment.

The plan also includes approval points for the charter, scope baseline, assessment baseline, and executive certification approval. These gates mark decisions leadership must make: accept the working definition of the effort, approve the assessment baseline, or escalate an unresolved issue before it reaches submission.

Cross-functional ownership matters because no single team can supply the full picture. Compliance can coordinate requirements and evidence. IT can reconcile systems and operating dependencies. Security can validate technical artifacts and document gaps. QA can test the assessment method and corrective actions. A smaller school system may combine these responsibilities, but it should still make the handoffs explicit to avoid accountability collisions.

2. Translate standards into evidence-backed assessment work

A policy library is not an assessment process. The plan separates source collection, requirements traceability, maturity-scoring rules, and control ownership before it asks teams to show how work operates. This creates a practical chain from a requirement to an accountable owner, an expected artifact, and an assessment conclusion.

The assessment-preparation phase then uses five distinct tasks: request evidence, interview control owners, validate technical evidence, conduct site and process walkthroughs, and build an assessment evidence index. The order matters. In the plan, technical validation follows the initial evidence request and control-owner interviews. Indexing follows validation and walkthroughs.

That sequence recognizes that evidence can be present but still be weak. A screenshot may not show whether a setting is current. A written procedure may not show whether a school-level process follows it. An owner may describe an operating practice that has no retrievable artifact. Interviews and walkthroughs help reconcile those differences before the assessment record is assembled.

The full evidence requests, validation, walkthroughs, and indexing tasks make this distinction visible. They also provide a useful foundation for teams that need to build an evidence-ready project plan: connect evidence to an owner, a requirement, a validation step, and a retrievability expectation instead of merely placing files in a shared folder.

Before executive approval and submission, the plan adds a separate evidence-retrievability task. That is a recommended assurance practice, not an asserted State-required test. It asks a practical question: can the organization find the material supporting its assessment assertions when a reviewer, leader, or successor needs it?

3. Treat remediation as a testable delivery stream

The maturity-assessment phase does more than score controls. It documents cybersecurity gaps, turns them into a remediation backlog, and obtains management approval of the assessment baseline. Without ownership, sequencing, and a decision on priority, a gap report remains an observation log rather than a delivery plan.

The actual corrective actions should depend on assessment findings. In this template, remediation categories include policy and procedure updates, technical safeguards, incident-response strengthening, and role-based training. These are examples of work streams that may be needed. They are not a complete or mandatory Maryland control list.

The strongest sequencing decision comes next: the plan requires a corrective-action retest before certification-package work can be finalized. A revised policy or deployed safeguard is not automatically proof that the underlying weakness has been addressed. Retesting gives the project team a defined point to confirm the intended change, identify remaining exceptions, and update the assessment record before leaders are asked to approve certification.

Prioritization also needs a portfolio mindset. The plan calls for a remediation backlog rather than an undifferentiated list of findings. Teams can use the backlog to rank work, then test what is feasible, while documenting why an item is addressed now, deferred, or escalated for leadership action.

4. Build post-certification monitoring into the original plan

Certification submission is the transition point in this plan, not its endpoint. The two post-submission phases establish recurring evidence collection, quarterly control reviews, a board cybersecurity dashboard, evidence-repository maintenance, reassessment milestones, a refreshed inventory, an interim self-assessment, and launch activities for the next formal cycle.

Maryland law requires a cybersecurity maturity assessment every two years and certification each June 30 every two years after the initial 2027 deadline. The plan's monthly and quarterly activities are recommendations for maintaining readiness between those formal statutory events. They can surface control drift, stale evidence, overdue remediation, and unresolved risk before the next assessment cycle.

The board dashboard matters when it supports decisions rather than simply reporting activity. The template identifies maturity, remediation aging, incidents, training, evidence currency, and material risks as examples of board-facing measures. A useful dashboard should clarify what has changed, what decision or escalation is needed, and who owns the next action. That is the same discipline behind a status report that leads to a decision.

The plan's recurring monitoring and two-year reassessment work keeps the next assessment from becoming a last-minute evidence chase. The initial certification project can close, but the controls, evidence, governance, and improvement backlog remain active responsibilities.

What this plan deliberately does not assume

The plan does not assume a universal technical control set, a fixed evidence format, a mandated scoring method, a staffing model, a cost estimate, or a calendar duration. It also does not establish the contents of an official certification package. Confirm those details against current State materials and local conditions.

That restraint is deliberate. A reusable plan can provide a credible structure for organizing the work without assuming that every district has the same systems, service providers, operating model, risk profile, or remediation backlog.

Inspect the full Maryland School System Cybersecurity Certification plan

The full plan contains all 38 task items across the nine phases described here. Review the task tree and the related Rules, Measures, Skills, and Tools before adapting the structure to your school system's current guidance, scope, ownership model, and assessment findings.

Inspect the Maryland School System Cybersecurity Certification plan