Network Operations Platform Requirements Checklist

Define the service outcome before selecting network tools

A network operations platform should help an operator protect a defined service: internet access, voice, messaging, transport, enterprise connectivity, managed infrastructure, or another communications product. Begin with customers, service commitments, physical and logical boundaries, critical journeys, and recent operational failures. “Single pane of glass” is not an acceptance criterion. It does not explain which data is authoritative, how service impact is calculated, or what an operator can safely change.

Map the operating loop from detection through triage, diagnosis, ownership, mitigation, customer or stakeholder communication, restoration, verification, and review. Identify existing inventory, configuration, telemetry, ticketing, workforce, customer, billing, and communication systems. Record waiting, duplicate entry, stale data, and unsafe manual work. Include night, weekend, vendor-escalation, and major-event conditions because the ordinary staffed path may conceal critical dependencies. The first release should shorten one measurable decision or recovery path rather than replace every specialized network-management system at once.

Establish trustworthy inventory and layered topology

Define stable identifiers for sites, devices, chassis, cards, interfaces, circuits, links, services, customers, addresses, software, licenses, vendors, contracts, and support ownership. Preserve source, observed time, effective period, confidence, and history. Separate physical inventory from logical and customer-service representations while linking them. A device can participate in several network layers, and a customer service can depend on multiple underlay resources that are not visible in one vendor console.

Model intended, configured, discovered, and observed state separately. Reconcile sources into an exception queue rather than allowing the latest import to overwrite conflicting evidence. RFC 8345 defines generic concepts for networks, nodes, links, termination points, supporting networks, and layered topologies; it is a useful reference model, not a requirement that every platform expose YANG internally. Acceptance should prove that operators can trace a service to supporting resources and identify stale or missing relationships.

Turn raw events into actionable alarm lifecycles

Normalize alarm type, affected resource, severity, first and last observation, state, source, probable cause, related alarms, impacted services, acknowledgement, assignment, shelving, clearance, and evidence. Preserve the raw event and transformation version so a changed correlation rule does not erase what the source reported. Distinguish an alarm condition from the operator workflow around it. A cleared signal may still require investigation, and an acknowledged alarm is not necessarily mitigated.

RFC 8632 separates resource, operator, and administrative alarm lifecycle concepts and includes root cause, impacted resources, related alarms, shelving, profiles, inventories, and summaries. Use those ideas to design consistent behavior across vendors. Correlate conservatively: group symptoms when shared topology, timing, and evidence support it, but retain access to individual signals. Test flapping, duplicate events, delayed clearance, missing resources, maintenance windows, and an incorrect root-cause hypothesis that an operator must reverse.

Connect incidents, service impact, and accountable decisions

An incident should record trigger, scope, affected services and customers where appropriate, severity rationale, commander or owner, timeline, hypotheses, actions, approvals, communications, restoration evidence, and follow-up. Keep observed facts separate from interpretation. Allow operators to link and unlink alarms without rewriting history. Define when an alarm becomes an incident, when several incidents merge, and when one event must remain separate because the response authority or customer impact differs.

Calculate impact from explicit dependencies and freshness. Show the data and assumptions supporting an affected-customer or affected-site number instead of presenting a precise count from stale topology. Provide manual correction with provenance when field evidence is stronger. Track time to detect, acknowledge, assign, mitigate, restore, verify, and communicate, but do not reward closing a record before service is stable. A useful system makes uncertainty visible and keeps the next responsible action clear.

Govern configuration and operational change safely

Inventory change paths: device CLI, controllers, orchestration, APIs, scripts, vendor portals, field work, and emergency access. Define request, peer review, authorization, target scope, dependency, precheck, maintenance window, execution, validation, rollback or forward repair, and closure evidence. Capture the intended change separately from the resulting operational state. Prevent a retry from applying a non-idempotent action twice, and require stronger confirmation for bulk or service-affecting operations.

Start with read-only correlation if configuration authority is not mature. Adding an automation button above inconsistent inventory and broad credentials increases risk. When write actions are justified, use narrow service identities, allowlisted operations, explicit device or cohort selection, time limits, concurrency controls, and an immutable audit trail. Test partial execution, loss of controller connectivity, a dependent service that fails validation, and rollback that cannot restore data-plane state automatically.

Design observability around customer-facing service behavior

Collect metrics, logs, traces, events, synthetic checks, flow or packet-derived evidence where appropriate, and business reconciliation without assuming one signal explains the service. OpenTelemetry describes observability as the ability to ask new questions from emitted signals and connects reliability measures to what users expect. Standard instrumentation can help correlate software services, but network protocols, appliances, and physical infrastructure will also require domain-specific telemetry and careful time alignment.

Define service indicators for availability, reachability, latency, loss, jitter, throughput, setup success, message delivery, DNS behavior, or another relevant outcome. Segment responsibly by service, geography, provider, device class, software, and customer tier. Make collection delay, sampling, gaps, clock source, and retention visible. Test the monitoring path itself: a network failure may prevent the platform from receiving the evidence needed to report it, so independent probes and degraded-mode procedures matter.

Protect privileged operations and sensitive network evidence

Apply strong identity, least privilege, separation of duties, session controls, credential rotation, and reviewed emergency access to network and platform administration. Segment management planes, protect configuration and topology exports, and avoid placing shared device credentials in application databases or automation scripts. Treat customer identifiers, locations, traffic metadata, support history, and security telemetry according to their sensitivity. Limit diagnostic bundles so a routine ticket cannot expose an entire network.

Plan detection, response, recovery, backups, vendor access, and supply-chain changes as part of the platform. CISA’s voluntary performance goals organize high-impact cybersecurity outcomes around governance, identification, protection, detection, response, and recovery. Tailor applicable goals to the communications environment and applicable obligations. Test compromised operator credentials, malicious API requests, unauthorized cross-customer searches, expired certificates, a disabled identity provider, and loss of the primary management region.

Require integration, recovery, and ownership evidence

Specify integration contracts for inventory, telemetry, tickets, customer records, workforce, notifications, reporting, and regulatory workflows. Define identifiers, source of truth, authentication, authorization, mapping, event order, idempotency, rate limits, retries, reconciliation, and operator recovery. Provide import previews and quarantine unknown records. A successful synchronization count does not prove circuits, services, and customers were matched to the correct operational entity.

Acceptance should exercise stale inventory, layered service impact, alarm storms, correlated and unrelated faults, maintenance suppression, partial change, provider outage, lost telemetry, emergency access, restoration verification, and export. Require client-controlled repositories and cloud accounts, schemas, integration mappings, runbooks, dashboards, alert routes, credentials, deployment pipelines, vendor inventory, and recurring-cost model. Use the DevOps and platform engineering improvement guide and cloud architecture requirements checklist, then share the network, services, sources, operator roles, scale, constraints, and recovery goals through the project questionnaire.

Authoritative references

• IETF YANG data model for network topologies
• IETF YANG data model for alarm management
• OpenTelemetry observability primer
• CISA Cross-Sector Cybersecurity Performance Goals

Related software planning guides

• Network Operations Platform Cost and Budget Guide
• Network Operations Platform Security Guide for Telecom Providers
• Network Outage Communications Workflow Guide