The review is the first step, not the whole of it.
Everything below is grouped by the one thing that decides whether we can do it remotely: what you have to send us. Nothing here needs an engineer in your building.
From a configuration file you export
Every rule, object and interface read in full. What is unreachable, contradicted, duplicated, or wider than anything else in the file requires.
The topology, the address plan, the VLAN and subnet map, the device inventory, drawn from your own configurations. Most networks have none of this and everyone knows it.
What is already past its vendor end of support, what dies and when, and a replacement order with the dates that force it.
Years of accumulation taken back out. Tiered so that what the configuration alone proves is never mixed with what only a counter suggests.
The exact lines that fix what we found, and beside every one the original line that puts it back, carrying the position it was removed from. Your engineer applies it in your window.
From a design, a drawing, or a supplier's quote
Your design, or a vendor's proposal and price, read by somebody with no stake in it before you sign.
Address plan, VLANs, switch and port count, power budget, edge and circuits, the equipment list, and the configurations written before the boxes arrive.
How you actually reach your cloud, direct connection against internet, and what your peering and transit should look like.
An addressing plan, a phased rollout, and an honest list of what breaks on the way.
What you are paying for, what you are using, and whether the design you are being sold fits either.
From data you already hold
Where the network is running out of road, from your own flow exports rather than from a probe we install.
What actually happened, read from the logs and configurations, and what stops it recurring.
On your equipment, in your change window
The cutover the lifecycle report calls for, prepared in advance and executed remotely at a time you choose.
The same configuration applied everywhere, which is the repetitive work that is cheap for us to prepare and quick for an engineer to approve.
Equipment configured before it ships and provisioned once it is powered on. Your hands rack it. Ours never touch it.
What we do not do, so you do not have to ask. No cabling, patching or physical installation. No penetration testing or vulnerability assessment. No ongoing managed service, monitoring or on call. Nothing server side: no operating systems, storage, backup, mail platforms or user support. We are a network practice and we stay inside that.
A file. That is the whole of it.
No credentials. No access to your network. No agent, nothing installed, no scan against your address space. If you can email us a file, the work can start, and if you would rather send it with the addresses masked, that works too.
Everything after that happens on our side. You are not booking an engineer's calendar and you are not opening anything up to a stranger. The one exception is the last group above, where we work on your equipment, and that only ever happens in a window you set.
A document your own engineer can check, line by line.
Not a tool output. Every finding carries the line of your own configuration that proves it, so your team can verify our work rather than take it on trust. Findings are ranked, and the ranking is spent carefully: one severity is reserved for what has to move today. Below is one finding from a rule review, as an example of the form. A documentation pack, a lifecycle report and a design review all carry their evidence the same way.
access-list outside_in extended permit ip any any access-group outside_in in interface outside
An access list applied on the outside interface permits every protocol from every source to every destination. Everything below it in the same list is unreachable, so the rules written later to restrict traffic are never evaluated.
The example is written by us to show the shape of a finding and the evidence that comes with it. It is not taken from any client's network.
Five reasons people actually commission one.
The engineer who built it has gone. No change log, no documentation, and nobody can say which rules still carry traffic.
Every change window is a gamble, because the effect of removing a rule cannot be predicted from what is written down.
ISO 27001, Cyber Essentials, PCI DSS and the German IT-Grundschutz all expect a periodic documented review by somebody independent of the people who wrote the rules.
A cloud move or a site consolidation has left rules pointing at subnets and servers that no longer exist.
The build running on the box has an end of support date, and nobody has checked it against the vendor's own published list.
The limit is stated here, not discovered later.
We work from the configuration file, so we can prove a rule is unreachable, contradicted, duplicated, or wider than anything else in the file requires. We can prove an object is defined twice under different names. We can prove a software build is past its vendor end of support.
We cannot tell you a rule is unused. Hit counters are not in a configuration file. Anyone who tells you which rules carry no traffic is reading exported statistics from your management platform, which is deeper access than we ask for. We will say a rule is structurally redundant, which is a different claim, and we will always say which one we mean.
Four steps, and one of them is ours alone.
Solander Wright is the network practice of Solander Partners. The work is done remotely, which is the design rather than a limitation. It means we can read a configuration from a company in another country without anyone travelling, and it means the only thing that ever changes hands is a file you chose to send.