Education & Nonprofit

Openness is the mission, not a mistake

Most security guidance starts from the assumption that a network should be closed by default. Schools, colleges and nonprofits cannot start there. A campus network exists to be used — by students on personal devices, by faculty running whatever their research or curriculum requires, by visitors, volunteers, contractors and the public. A nonprofit’s network often serves the community it was created to help. Locking it down defeats the purpose of having it.

So the work is not restriction, it is separation. Student information, financial systems, HR records, donor databases and building controls each need real boundaries around them, while the open parts of the network stay open. Done well, the openness stops being a security problem because the things that matter are no longer reachable from it.

The second constraint is resourcing, and it is severe. A district may run a dozen buildings with a handful of technicians. A nonprofit may have no IT staff at all and a board that reasonably asks why money is going to infrastructure rather than programs. Both sectors are targeted heavily anyway — schools for the student data and the disruption, nonprofits for donor and financial records — and neither can spend its way out. The design has to be defensible on a budget that will be questioned.

Where we focus

Segmenting the systems that matter

Real enforced boundaries around student information systems, finance and payroll, HR records and donor databases, so an open network and a compromised personal laptop reach neither. This is the highest-value work in both sectors: it is what allows the rest of the network to stay genuinely open without that being reckless.

Campus wireless at density

Coverage and capacity designed for real conditions — a lecture hall where three hundred people connect at once, dormitories where every student brings several devices, gymnasiums and auditoriums that fill for events, and outdoor spaces that are expected to work. Authentication that distinguishes a school-owned device from a student’s phone from a visitor, and places each accordingly. Density and roaming are usually the difference between wireless that works and wireless that generates complaints.

Student, guest and BYOD networks

Personal and guest devices kept on networks with no route to administrative or academic systems. In K-12 this sits alongside the content filtering obligations that come with CIPA and E-Rate participation; in higher education it has to accommodate residential networks that behave, in practice, like a small ISP.

Building systems and campus infrastructure

Cameras, door access, HVAC, bell and PA systems, and increasingly classroom technology all sit on the network, and in schools some of them are safety systems. They belong in their own zones with scoped vendor access. See Smart Building & IoT for that work in more depth.

Multi-site and multi-building estates

Districts, campuses and nonprofits with several locations get one standard design rather than a different build per building, so a small team can support all of them and a change is a scheduled task rather than a tour.

Designs that survive a budget review

Phased so the highest-risk gaps close first and the rest can follow as funding allows — because in these sectors funding genuinely does arrive in stages. We would rather scope work that gets approved and built than a complete architecture that sits unfunded for three years.

How we engage

The same three phases as the rest of our work. Start at any of them; many organizations come to us with a grant deadline, a refresh cycle, or an incident at a peer institution that prompted the board to ask questions.

On funding and compliance

These sectors carry a particular mix of obligations: FERPA around student education records, CIPA where E-Rate discounts are taken, state student privacy laws, PCI DSS wherever payments or donations are processed by card, and grant conditions that increasingly include security requirements of their own.

We build and operate the technical controls those obligations call for and produce the evidence to demonstrate them. On funding, we are glad to scope and document work so it fits an E-Rate or grant application and to work with whoever manages that process for you — but we are not E-Rate consultants and do not determine eligibility or file on your behalf. Program rules change and eligibility depends on the applicant and category of service, so confirm any eligibility question with the program or your consultant before relying on it. See Compliance & Risk for how assessment and readiness work is structured.

Who this is for

• K-12 districts and independent schools running multiple buildings with a small technology team.
• Colleges and universities balancing academic openness, residential networks and administrative systems on one campus estate.
• Nonprofits and foundations holding donor, financial and beneficiary data without dedicated IT staff.
• Organizations with a grant, capital project or refresh cycle that is an opportunity to fix the underlying design rather than extend it.
• Institutions whose board or leadership has started asking where they stand after a ransomware incident in the sector.