Why an open source phone system for education needs a different build
An open source phone system for education is a self-hosted PBX designed around direct 911 dialing, building-level location, paging and bell control, and license costs that fit public budgets. For a district or university IT lead facing a PBX refresh, that definition matters because a campus phone system is not one switch in one room. Every building, gym, portable classroom and dormitory line has to dial 911 directly, and the notification has to reach a staffed front office. The common open-source base for this work is Asterisk with FreePBX, which provides the call control, dial plans and administration layer. Confirm with your telephony partner which Asterisk line and FreePBX version they will deploy, and check its lifecycle before committing, since support windows differ between releases.
Student data rules shape where the phone system keeps its records. FERPA's regulations in 34 CFR Part 99 apply to any educational agency or institution that receives funds from a program administered by the Secretary of Education, and voicemail, call detail records and recordings can all contain personally identifiable information about students and families. Under 34 CFR 99.31(a)(1)(i)(B), an outside contractor may act as a school official only when it performs a service the institution would otherwise perform with its own employees and remains under the institution's direct control. Put that question to every hosting and support vendor early. Decide where call detail records, voicemail and recordings are stored, who can retrieve them, and how long they are kept. Also check whether any cloud-hosted or SaaS component sits in that data path, because its contract terms will govern the answer.
Access and logging decisions follow from those rules. Under 34 CFR 99.31(a)(1)(ii), the institution must use reasonable access controls so that school officials see only the records tied to their legitimate educational interest, which means separating administrator roles for the PBX from roles that can read voicemail or call logs. Under 34 CFR 99.32, the institution must also keep a record of each disclosure of personally identifiable information from education records, which a phone platform should be configured to support. Ask your partner to document the admin role model, the audit logging of PBX and voicemail access, and the retention settings in writing before cutover, since these are the controls a FERPA reviewer will ask about first.
Which education requirements change the phone system build
This table maps each education rule that touches school and campus phones to the part of the build it changes, including dial plan, notification paths, location data, admin access and retention. Read each row as a question to settle with counsel, your carrier and your records office before the design is frozen.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| Kari's Law direct 911 dialing | Multi-line systems must let users dial 911 without a prefix, and send a notification to a central location when 911 is dialed. Confirm exact scope with counsel and the carrier. | Dial plan routes 911 directly on every extension and trunk, with no access code. Notification path must reach a staffed front office or security desk, tested on every site. |
| Dispatchable location for classrooms and buildings | Emergency responders need a usable address and room or building detail for calls from campus phones. Confirm the location standard that applies to your state and phone type. | Each phone or port needs a location record that identifies building, floor and room. Keep the location table current after moves, new classrooms and softphone use off campus. |
| FERPA access controls for call records | Only school officials with a legitimate educational interest may access education records, using physical or technological access controls (34 CFR 99.31(a)(1)(ii)). | Restrict CDR, recording and voicemail access by role in the PBX admin console. Use named accounts, separate admin and reporting roles, and review access on a set schedule. |
| FERPA disclosure logging | Institutions must record each request for and disclosure of personally identifiable information from education records, kept as long as the records are kept (34 CFR 99.32). | Enable audit logs for admin changes, voicemail playback and recording downloads. Set log retention to match the retention schedule your records office defines. |
| FERPA contractor as school official | A contractor may receive records only for a service staff would otherwise perform, under the institution's direct control, and with redisclosure limits (34 CFR 99.31(a)(1)(i)(B)). | Put partner access behind named, time-limited accounts. Contract terms should set data use, return or deletion, and the institution's control over admin access. |
| COPPA for younger students | Operators collecting data from children under 13 must keep a written security program and a retention policy with a deletion timeframe (16 CFR 312.8 and 312.10). Confirm applicability with counsel. | Applies mainly if a vendor or app collects data from young students through the phone stack, such as parent-facing notification apps. Set deletion timers for voicemail and call data tied to those users. |
| GLBA Safeguards Rule for Title IV institutions | Title IV institutions must follow the Safeguards Rule, including a written information security program and MFA for anyone accessing any information system (16 CFR 314.4(c)(5)). | Require MFA on PBX admin, reporting and partner portals, and on remote administration paths. Document the written program and tie phone admin accounts to it. |
Which open source PBX stacks fit schools and universities
School districts and universities usually land on one of a few telephony patterns, and each has different staffing and budget consequences. The cards below cover the PBX core, the contact center layer, the parts of the phone stack that shape call quality and reliability, and the collaboration tools that sit beside telephony under their own licence and hosting terms.
Asterisk with FreePBX as the core
Asterisk with FreePBX is the most common open-source base for district and campus PBX work, giving a web administration layer for extensions, ring groups, inbound routing and voicemail. Because the core software carries no per-user license fee, budget discussions focus on servers, trunks, handsets, support and implementation hours. Confirm the Asterisk release line and its LTS or security-fix status with the vendor before you commit, and confirm FreePBX compatibility with that release, since both move on their own published schedules.
Contact center add-ons for university call centers
Admissions, financial aid, registrar and student services lines often need queues, skills-based routing, call recording and agent reporting that a basic PBX does not provide. Asterisk can host these functions, but many campuses add a commercial module or a separate open-source project for agent desktops and reporting. Ask each option for its license terms, its recording retention controls and whether it is tested against your Asterisk release before you plan staffing around it.
Trunks, handsets and softphones
The PBX software is only one part of call quality and cost. Your SIP trunk provider determines number porting, emergency calling behavior, call capacity and outage handling, and handsets and softphones determine audio quality, provisioning effort and how staff in dorms, labs and off-campus offices stay reachable. Ask trunk providers to describe their 911 handling and failover, and ask handset vendors which firmware and provisioning methods they support with your FreePBX version.
Collaboration tools chosen separately
Voicemail storage, staff alerts and virtual classrooms often run on tools beside the phone system, such as Nextcloud for voicemail file storage, Mattermost or Rocket.Chat for staff alert channels, or BigBlueButton for virtual classrooms. Each of these carries its own license and hosting terms, so choose it on those terms, not as a side effect of the PBX decision. Check whether the license applies to modified code, whether a commercial edition is required for features you need, and where the data sits.
Confirm versions and support status
School and university projects often outlast the staff who selected the platform, so the version you deploy determines your support window. Ask the vendor or implementation partner for the current release line, its security-fix end date and the upgrade path for FreePBX and your handsets. Put that answer, along with the named support contact, in the written scope before procurement closes.
How a district or campus phone rollout moves from inventory to cutover
The sequence turns scattered lines, rooms and bell schedules into a tested telephony design that each building can cut over to without losing emergency calling or front office coverage.
Inventory buildings, rooms and lines
Collect a full inventory of every building, room, extension, analog device, fax line, elevator phone, emergency phone and paging zone, along with the current carrier circuits and numbers. Record which bell schedules, intercom zones and door systems depend on the phone network, since these often break first during a move. The phase is complete when the district or campus IT lead and the facilities team have both signed off on the inventory, and every device has an owner and a planned disposition (keep, replace or retire).
Design 911 and dispatchable location
Map each building, floor and room to a dispatchable location that the emergency notification and 911 routing design can use, including how classrooms, gyms, portable buildings and outdoor areas are identified. Confirm with your state and local 911 authority and your carrier what notification recipients are required and how location is delivered. The output is a location map that the front offices and safety staff have reviewed, plus a written notification design that names who receives the alert and how.
Build the dial plan and trunks
Translate the inventory and location map into a dial plan covering internal extensions, emergency dialing, outbound rules for staff and students where applicable, and inbound routing to the main office and departmental lines. Configure SIP trunks and numbers with the carrier, and confirm that the platform can present the correct caller and location data on emergency calls. The phase closes when a lab build reproduces the dial plan and every emergency route is recorded in a version-controlled configuration.
Test the emergency notification path
Run scripted test calls from each building type to the 911 test path and to the notification recipients, covering handsets, softphones and any alternate or mobile endpoints in use. Record the result of each test, including the time the notification arrived, the location data delivered and any failures and fixes. The output is a signed test record that the district or campus safety officer, the IT lead and the carrier contact have each reviewed before any production line moves.
Pilot in one building
Move one building with a representative mix of classrooms, front office lines, paging zones and bell integration onto the new platform while the legacy system stays in service as a fallback. Test bell schedules, paging, intercom and after-hours routing under normal school operations, and log every issue with a named owner. The pilot is complete when the building operates through its normal cycle without an unresolved emergency or front office defect, and the lessons are written into the cutover runbook.
Port numbers and cut over by site
Plan the number porting order with the carrier, starting with lines that carry the least operational risk and ending with the main office and emergency-critical lines. Cut each site over in a short, pre-approved window with a documented rollback path, a named on-call engineer and a checklist for confirming inbound calls, outbound calls and emergency tests after the switch. The phase produces a site-by-site cutover runbook with a completed record for each site and a clear state for any numbers still in porting.
Train front offices and staff
Train front office staff, nurses or health aides where relevant, teachers, facilities staff and building administrators on the new handsets, paging, emergency dialing, voicemail access and how to report a fault. Provide quick reference material for each building and record who attended. The phase is complete when each front office has demonstrated emergency notification handling and fault reporting, and the support contacts and escalation path are published for after-school and holiday periods.
How district, campus and hybrid deployments change the design
A single district with many schools usually runs one central PBX with a branch at each school, or one central system serving every building over a private WAN. The main design questions are how each school's fixed phones report a dispatchable location and how the front office receives notification when a staff member dials 911. Classroom phones are often fixed, so location can be tied to the building and room, but any mobile or softphone used on field trips or by coaches needs a registered location update process. Survivability matters because a WAN outage should not stop emergency calls from the school. Administration is usually split between a small district IT team and a partner, so the FERPA school official conditions apply to any outside administrator who can reach call detail records or voicemail.
- 911 location per school: Each building's phones should carry a dispatchable location that matches the address and room layout that responders use, and the district should confirm that the record is kept current after renovations or room changes.
- Survivability: Ask whether each school can place local calls and reach 911 through a local trunk or a local media gateway if the WAN to the central PBX fails.
- Non-fixed phones: Coach phones, nurse carts and mobile devices need a documented process for updating their location when they move between buildings.
- Administration boundary: Define which district staff, and which partner staff under direct control, can access call detail records and voicemail, and log those accesses.
- Central notification: Confirm which front offices, security staff or district safety personnel receive the notification, and test the path from each school.
Before you commit, check the per-school location records, the local failover test results and the list of partner accounts with access to student-related call data.
A university with many buildings and residence halls has a different problem. Phones are spread across academic buildings, labs, dormitories, athletics facilities and administrative offices, and many residents bring their own devices and softphones. Dispatchable location must resolve to building, floor and sometimes room for fixed phones, and it must handle the case where a student calls from a personal device on the campus Wi-Fi. Survivability often depends on whether the campus network core has redundant paths. Administration is typically a mix of central IT, departmental staff and any outside partner, so FERPA control depends on documented role boundaries and access rules that restrict education records to staff with a legitimate educational interest.
- Building and floor location: Residence halls and multi-floor academic buildings need location records at the floor or room level, and the registry should be maintained with facilities data.
- Non-fixed and personal devices: Confirm how the system obtains location for softphones on campus Wi-Fi and what happens when a resident calls 911 from a personal phone off the network.
- Survivability: Ask how the design behaves when a building switch or core link fails, and whether each residence hall can route emergency calls locally.
- Access control: Use role-based access so that only staff with a legitimate educational interest can reach student call records, and keep the access log that FERPA requires.
- Partner control: Any outside administrator should work under the institution's direct control, with the use and redisclosure limits written into the contract.
Before you commit, confirm the building-level location registry, the failover test for the network core and the access model for each administrative group.
A hybrid design hosts the PBX in a cloud account or a managed data center while keeping local gateways, handsets and emergency routing at the institution's sites. This model reduces the number of on-premises servers, but it moves emergency routing and call data into a third-party environment, so the institution must keep control over configuration, keys and access. Dispatchable location still has to be delivered for every phone, including those that register through the cloud PBX from a remote site. Survivability depends on whether local gateways can continue to place calls when the path to the cloud fails. Administration should stay with the institution, with the partner operating under a written agreement that gives the institution direct control over use and maintenance.
- Location through the cloud path: Confirm that location data reaches the emergency routing function without depending on the cloud region being reachable.
- Local survivability: Ask whether on-site gateways can place 911 calls and route notification to local staff when the cloud link is down.
- Institutional control of accounts: The institution should hold the administrator credentials, the encryption keys and the audit logs, not only the partner.
- Data location and access: Know which regions store call detail records and voicemail, and which staff can open them.
- Exit and continuity: Document how the institution would move the configuration and numbers if the hosting arrangement ended.
Before you commit, check the cloud provider's contract terms, the local gateway failover test and the list of accounts with administrative rights.
Integration points that carry student and staff data
A school phone system is rarely standalone. Extension lists, bell schedules, paging, emergency alerts, voicemail and admin logins all draw on systems that hold student or staff records. Each connection needs a defined data scope, a named owner and an access rule that the district or university can explain to a FERPA reviewer.
Student information system sync
Extension and directory sync pulls names, roles, building codes and sometimes student-linked records from the student information system into the PBX directory. Limit the sync to staff and published directory fields, and exclude student records unless a specific use needs them. Ask who approves each field, how terminated staff and withdrawn students are removed, and whether the sync account can only read the fields it needs. Under FERPA, a vendor or integrator that receives education records must be under the institution's direct control and must be limited to the records its service requires.
Paging and bell controllers
Bell schedules and paging zones are often driven by controllers that accept commands from the PBX or from a scheduling service. These devices carry building and zone information rather than student records, but their management interfaces can reach the same network as the PBX. Confirm which accounts can change bell schedules or trigger all-call paging, that controller admin pages are not exposed on the internet, and that changes are logged. Ask the controller vendor whether it supports per-zone permissions and which firmware versions receive security updates.
Door and emergency alert systems
Lockdown notifications, door status and emergency alert feeds may reach the front office through the phone system. These messages can reveal the location of students or staff during an incident, so treat them as sensitive operational data. Define which alerts are pushed to phones, who can start an alert, and what gets written to call logs. Test failover paths, because an alert that depends on a single trunk or server fails when it is needed most. Confirm the integration design with the school's safety team and the alert vendor.
Voicemail and call recording storage
Voicemail and recordings from counseling offices, athletics, special education or front desks can contain student names, health details and family information. Decide where audio files are stored, how long they are kept, who can retrieve them, and how deletion is carried out and logged. FERPA requires institutions to record each disclosure of personally identifiable information from education records, so retrieval by staff should be traceable. Ask whether the storage location is inside the district's own infrastructure and whether encryption at rest is configured for recording and voicemail directories.
Identity provider for admin and softphone logins
Administrator access to the PBX and softphone registrations for staff should authenticate through the district or university identity provider rather than local passwords alone. This limits access when someone leaves the institution and gives an audit trail for changes to the dial plan and recordings. Confirm that multi-factor authentication covers administrator accounts, that service accounts are separate from personal accounts, and that softphone credentials can be revoked centrally. Where the institution falls under the GLBA Safeguards Rule through Title IV participation, multi-factor authentication for anyone accessing an information system is a stated requirement.
Monitoring and call detail records
Call detail records, registration status and system logs show who called whom, when and from which location. These records are useful for 911 testing evidence and for investigating misuse, but they also reveal student-related calls, such as calls from counseling offices. Set a retention period for call detail records and logs, restrict access to administrators with a defined need, and review who exports them. FERPA requires institutions to keep records of disclosures, and HIPAA-style audit expectations are a useful model for log review even when they do not apply directly. Ask the partner how logs are forwarded, protected and retained.
What auditors and regulators ask for from a school phone system
This table maps each piece of evidence a FERPA, GLBA or 911-related review may ask for to the component that produces it and the common gap that delays it. Use it to plan logging, identity and paperwork before an assessor or district reviewer asks. It does not describe an audit result, and the controls it names must be confirmed against your own institution's scope and counsel's reading of the rules.
| Evidence item | Producing component | What the reviewer expects to see | Common gap |
|---|---|---|---|
| Disclosure record for student records (34 CFR 99.32) | Central syslog and records system of record | Who requested or received personally identifiable information, the legitimate interest, and the date, kept as long as the records are kept | Phone and voicemail access by staff is not logged centrally |
| Admin and records access logs | PBX logs forwarded to central syslog, identity provider | Named admin sessions, configuration changes and access to call detail or voicemail, with time stamps | Shared admin accounts or logs kept only on the PBX and overwritten |
| Role-based access tied to legitimate educational interest (34 CFR 99.31) | Identity provider and PBX role mappings | Written role matrix showing which staff can view recordings, voicemail or call records and why | Roles granted by default to all front office staff without review |
| MFA configuration for administrative and remote access (16 CFR 314.4) | Identity provider and PBX admin interface | Settings showing multi-factor authentication required for anyone reaching an information system, plus exception records | MFA covers the portal but not SSH, the database or the softphone provisioning service |
| 911 test records and notification logs | PBX dial plan, notification service and ticketing system | Dated test call results, front office notification confirmations and corrective tickets for any failure | Tests run once at go-live with no retest after changes or moves |
| Retention settings for call records and voicemail | PBX configuration and storage policy | Written retention schedule with the configured deletion timeframe and proof that purges run | Voicemail kept indefinitely on the PBX with no owner for the schedule |
| Written security program and risk assessment | Governance documents and ticketing system | Named coordinator, written program covering the phone platform, and dated risk assessment results with tracked remediation | Telephony missing from the institution's security program or risk register |
| Contractor agreement showing direct control | Contract, statement of work and access records | Contract terms limiting use and redisclosure, named administrators, and records showing the institution approves access | Implementation partner holds admin credentials with no institution-side approval trail |
What education buyers ask before hiring a phone implementation partner
What drives the cost of an open-source phone system for a school district?
Cost depends mostly on building count, number of sites, handset counts, trunk and number requirements, and how much integration the district needs with bells, paging and notification tools. The software itself is license-free for Asterisk and FreePBX, so the spend sits in hardware or cloud hosting, SIP trunks and numbers, handsets, implementation, porting, and ongoing support. Some costs are one-time, such as design, build, testing and handset purchase. Others recur, such as trunks, numbers, hosting, support retainers and upgrades. Ask any partner for a written quote that separates these lines and states who pays each vendor directly.
How long does a district phone rollout take?
Duration depends on how many buildings are involved, whether numbers must be ported from an existing carrier, how many dial plans must be rebuilt, and how much testing the district requires before cutover. A single campus with few numbers moves faster than a district with dozens of buildings, each needing its own 911 location data and paging zones. Porting lead times are set by carriers, not by the implementer, so request the porting schedule in writing. Ask for a phased plan that cuts over pilot buildings first, and confirm the timeline in the fixed-scope document before work starts.
What does the district IT team need to contribute?
The IT team usually supplies network access, firewall and VLAN changes, quality of service settings on switches, identity and directory access, and a named person who can approve cutover windows. Someone must also own the 911 location records, because only the district knows which room or building a phone sits in. Expect the team to review the design, attend testing, and learn the admin console before handover. Ask the partner to list every task it expects from your staff, with hours or roles, so the scope is clear before the contract is signed.
Can a district run its own open-source PBX without a partner?
A district with experienced telephony engineers can run Asterisk or FreePBX internally, but the staff must cover 911 configuration, SIP security, backups, monitoring, upgrades and after-hours response. Many districts have small IT teams that cannot absorb these tasks during the school year. A common model is to buy the design, build and testing from a partner, then keep in-house ownership of daily administration with a support retainer for upgrades and incidents. Ask any provider to state which tasks it hands over, and what documentation you receive at the end.
How are Kari's Law direct dialing and 911 notification tested?
Testing should prove that a user can dial 911 directly without a prefix, that the call reaches the correct public safety answering point, and that notification reaches a designated front office staff member at the same time. Testing should also cover each building and each phone type, including softphones and any phones used off premises. Keep dated test records, screenshots or call logs, and sign-off forms for each site. Use FERPA-aware practice for those records, since they can show which staff received alerts. Confirm the exact test plan and evidence format with your state and local authorities.
What does FERPA require from a phone vendor that handles student information?
FERPA's regulations (34 CFR Part 99) apply to any educational agency or institution that receives funds from a program administered by the US Secretary of Education. Under 34 CFR 99.31(a)(1)(i)(B), an outside contractor may receive education records only as a school official, under the institution's direct control, and subject to redisclosure limits. In practice, call detail records, voicemail and any notification content that identifies a student must be limited, logged and access-controlled. Ask the partner to describe its access controls, logging, and data handling in writing, and confirm the contract terms with your counsel.
How does licensing differ from per-seat hosted phone plans?
Asterisk and FreePBX do not charge per-seat software licenses, so the recurring cost moves toward hosting, trunks, numbers, support and any commercial add-ons you choose. Hosted per-seat plans bundle software, hosting and some support into a monthly fee for each user, which can be simpler to budget but adds cost as staff or classrooms grow. Compare total cost over the contract term, including handsets, porting, 911 features and support levels. Ask each vendor to show every recurring line item, and check whether features you need, such as paging or notification, are included or sold separately.
What to ask an education phone implementation partner
Start with 911 and notification, because a school's obligations are tested building by building. Ask the partner how they will verify that each building's phones dial 911 directly without a prefix, that the notification reaches the front office or designated staff in every building, and that the dispatchable location sent with the call matches each room or floor on the campus. Ask for the test script, who runs it, whether it is repeated after every dial plan change, and how results are recorded. For a district or campus with many buildings, ask whether they will test from a sample phone in each building or from every phone type in use, such as classroom desk phones, wall-mounted phones in corridors and gymnasium or outdoor units. Request a written test plan and a signed results sheet before cutover.
Next, ask how the design documents FERPA direct control and access restriction. Under 34 CFR 99.31(a)(1)(i)(B), a contractor may handle education records as a school official only under the institution's direct control, so ask the partner to show which administrator holds the admin credentials, where the configuration and call detail records are stored, and who can export them. Ask how role-based access limits staff to the phones, voicemail boxes and recordings their legitimate educational interests require, and how access grants and removals are logged. Confirm that the institution, not the partner, can disable remote access to the PBX. Request the access matrix, the contract language on redisclosure, and a sample of the access log as deliverables before work starts.
Ask how voicemail, call recordings and paging logs containing student names, guardian details or health information are stored, encrypted, retained and deleted. Ask which retention period the partner will configure, who approves it, and how deletion is verified and logged. Confirm how bell schedules and paging failures are handled: whether the bell controller and paging amplifier sit on a monitored path, what happens if the SIP trunk or the PBX fails, and whether a manual fallback is documented for the front office. Ask for the upgrade policy in writing, including how Asterisk and FreePBX versions are chosen, how security patches are applied in a school calendar, and the support hours for summer and emergency changes. Confirm which items are covered by the fixed-scope agreement and which need a retainer. The partner should give written answers before any work starts.
How DeployOpen scopes and supports an education phone system
This sequence turns a district or university telephony need into a written, fixed-scope build plan, a tested deployment inside your own infrastructure, and documentation your compliance team can review. DeployOpen prepares the evidence, while your auditors and counsel make the compliance determinations.
Confirm the sites, users and phone roles
DeployOpen starts with a discovery session to inventory every campus, building, classroom, front office, bell and paging zone, and emergency phone that will be on the system. Your IT lead, facilities contact and a school safety or emergency management representative take part, because the design depends on who answers which line and where each handset sits. The step closes with a site and user register that lists each endpoint, its physical location and its owner, which becomes the baseline for 911 and location testing.
Agree on a fixed-scope written statement
Before any build work, DeployOpen issues a written scope that defines deliverables, integrations, testing responsibilities, exclusions and timelines, and that your procurement and legal teams can review. Because the scope is fixed, changes such as added buildings or a new paging integration go through a written change request. The step is complete when both parties sign the scope and your contract owner confirms which data your district or institution remains responsible for.
Review data handling and FERPA responsibilities
DeployOpen reviews where call detail records, voicemail, recordings and directory data will be stored and who can access them, and identifies which records could contain personally identifiable information from education records. Your counsel decides whether DeployOpen qualifies as a school official under your FERPA policy and sets the contract terms that govern use and redisclosure. The output is a data flow map and an access list that you approve, and it becomes an input to your FERPA compliance file.
Build and configure the PBX inside your infrastructure
DeployOpen installs Asterisk and FreePBX in your data center, cloud account or private network, configures trunks, dial plans, direct 911 routing and notification paths to front offices, and integrates bells, paging and any approved SIP devices. Hardening covers administrative access, SIP exposure and logging so that the system can support the audit control expectations described in your security policy. The step closes when configuration is recorded in version-controlled documentation and a build sign-off is approved by your team.
Run building-level 911 and location tests
DeployOpen runs test calls from each documented endpoint, records the location data the system presents to the emergency call center and confirms that notifications reach the designated front office staff. Results are logged per building and per room group, with failures tracked to a fix and a retest. Your emergency management lead reviews the records, and the step is complete when every endpoint in the site register has a passing test entry, or an approved exception with a remediation owner.
Document controls and retention evidence
DeployOpen assembles the system description, configuration baseline, access list, test records, retention settings and change history into an evidence pack organized for your compliance and audit teams. Where a FERPA access log or disclosure record is needed, the pack explains how the system captures it and where it is kept. DeployOpen prepares this material but does not issue audit reports or certifications, so your independent assessors decide whether it meets your obligations. The step closes with a delivered, versioned evidence set.
Hand over and transfer operating knowledge
DeployOpen trains your administrators on dial plan changes, user onboarding, endpoint replacement, backup restoration and the 911 test procedure, then delivers runbooks tied to the documented baseline. Your staff run a supervised change exercise to confirm they can apply a routine update without breaking emergency routing. The handover is complete when your administrators have performed the exercise and signed the operations runbook.
Continue support under an optional retainer
If your institution wants ongoing help, DeployOpen can offer a support retainer covering upgrades, security updates, periodic 911 retesting and documentation refreshes, with the scope and response expectations written into the agreement. Retainers are priced from the written scope, and you should ask for the recurring components, the change request process and how retesting is billed. The step is complete when the retainer terms are signed, or when you choose to run the system without one and the handover package is accepted.
