Connect. Secure. Manage.
Network Acceptance Testing
Test a new Cisco or Meraki network against agreed requirements, covering application access, failover, security controls and operational handover evidence.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Network acceptance testing establishes whether a delivered network meets the requirements that justified the work. MCI develops and carries out test programmes for Cisco and Meraki deployments, connecting the technical build to the services users and applications need. The result is evidence for an acceptance decision, not simply an installation checklist with every box marked complete.
Testing is most useful when its criteria are agreed before the change. That gives the implementation team a clear target and helps the business distinguish an acceptable limitation from an unresolved defect. It also prevents completion from depending on an informal judgement made at the end of a long maintenance window.
A clear requirement
Turn the business need into a practical network scope with visible dependencies.
A controlled delivery
Plan implementation, testing and rollback before production changes begin.
A supportable result
Leave useful records, ownership and escalation routes behind.
Connect every important test to a requirement
We identify the outcomes the network must deliver and the observations that will demonstrate them. Connectivity, authentication, permitted access, isolation and recovery may each need different tests and different people to confirm the result.
The test plan distinguishes network evidence from application acceptance. An engineer can establish that the expected path is available, but the application owner may need to confirm that a business transaction or specialist feed behaves correctly.
Where requirements are vague, the plan exposes that before execution. A statement such as “the network must be fast” needs an agreed context and observation method before it can support a meaningful pass or fail decision.
Standards & partnerships
Confidence in the team behind your network.
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Check normal operation and access boundaries
The programme includes representative users, devices and services rather than testing only the installation engineer’s laptop. Different authentication methods, network segments and site patterns may require separate checks.
Successful access is only half the picture. Where the design requires separation, the test should also establish that inappropriate communication is not permitted. Guest access, management networks and third-party connections are common examples where the intended boundary matters.
The tests are proportionate to the scope. A targeted change does not necessarily require retesting the entire estate, but dependencies and potential side effects should be considered before deciding what can safely be excluded.
A useful starting point
Tell us what is happening.
A short description of the problem is enough for an initial discussion.
Verify the agreed failure and recovery behaviour
Where resilience is part of the design, the plan defines the failure scenarios, expected outcomes and stop conditions. Tests that could disrupt production require explicit authorisation, preparation and an understood recovery route.
We observe the resulting service, not just the state of a routing protocol or a dashboard indicator. The surviving path may be available while an application remains unable to recover, or the network may restore access through a path that does not apply the intended security policy.
The return to normal operation is tested where relevant. A system that fails over successfully but cannot be restored predictably still has an operational issue that should be understood before acceptance.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Keep test evidence traceable to the delivered build
Results identify the configuration or build version, test conditions, observation points and participants. This makes the evidence useful when a question arises later about what was actually tested.
A screenshot without context can be difficult to interpret. Logs, measurements and a concise account of the method help distinguish a verified result from an assumption. Sensitive information is handled appropriately and is not included unnecessarily in widely circulated reports.
When a change is made after a failed test, the relevant tests are repeated. The acceptance record should not combine results from incompatible build versions as though they describe one final state.
Make exceptions and the acceptance decision explicit
Not every issue has the same significance. We distinguish defects that prevent acceptance from lower-impact actions that can be completed later, subject to the customer’s decision. Each exception needs an owner and an agreed next step.
Some tests may be deferred because a provider, application or site is unavailable. That limitation is recorded as untested, not marked as passed. The business can then make an informed decision about whether the remaining uncertainty is acceptable.
The output feeds into handover and ongoing support. Operational teams receive the delivered-state information and know which behaviours have been verified, which conditions were not tested and which actions remain open.
Acceptance testing questions
Can you test a network installed by another supplier?
Yes, with an agreed scope, authorised access and sufficiently clear requirements. The purpose is to assess the delivered service against those requirements. We distinguish testing from responsibility for correcting any defects identified.
Is acceptance testing the same as a security audit?
No. It can verify specified security behaviours, such as isolation or authentication, but it is not automatically a comprehensive security assessment or penetration test. Those activities require their own scope, methods and authorisation.
Can tests be performed without affecting users?
Some can, while others intentionally examine failure or change behaviour. The plan identifies likely impact and the necessary maintenance window. We do not assume that a useful resilience test is non-disruptive simply because the design includes redundancy.
What should we arrange before commissioning tests?
The accepted design, requirements, build information and application-owner availability are the starting point. Plan network acceptance testing early enough for the criteria to guide implementation rather than being invented after the network has been installed.
Talk to a specialist
Need a specialist view?
Tell us what is affected, what changed and what your team has already checked. A short outline is enough to start.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.