The security model
Published in full, with the defaults stated and the exceptions described, because a security posture that cannot be inspected is a claim rather than a posture.
What is on by default
Encrypted signalling and media wherever the endpoint supports both. Address-based authorisation for fixed sites, which removes the credential rather than protecting it. Destination policy that denies everything and permits only what the organisation actually calls.
Concurrency and spend thresholds that contain automatically rather than notify. Role-based administrative access with individual, attributable accounts and no shared credentials.
Turning any of these off is a recorded decision attributable to a named person, reviewed at the next service review. It is not something that quietly happens because an endpoint made it inconvenient.
Why the thresholds contain rather than alert
Toll fraud is automated, non-targeted and continuous, and it begins outside working hours because the variable it exploits is detection latency rather than technical difficulty.
An alert into an unattended inbox on a Friday evening is not a control. It is a record of what happened, delivered after it finished.
So the thresholds act: concurrency ceilings, rolling spend limits and destination deviation, each capable of stopping traffic on their own. We accept occasional false positives as the price of a control that works while nobody is watching.
What each control produces
Every control here generates an artefact rather than only a behaviour. Configuration records for the encryption and authorisation settings. A policy record plus change history for destination policy. Threshold configuration and an alert log for containment. An access log and a periodic review record for administrative access.
The reason is practical: a control you cannot evidence is one you will have to demonstrate from memory during an audit, and memory is a poor evidential basis.
What we do not claim
This page describes a technical posture. It does not assert any certification, accreditation, regulatory approval or carrier authorisation, and nothing elsewhere on this site does either.
Where a specific status bears on your procurement process, ask directly and the answer will be precise and in writing, including where the precise answer is no.
Protection by boundary
| Boundary | Control | Evidence produced |
|---|---|---|
| Connectivity | TLS signalling, SRTP media | Per-trunk configuration record |
| Connectivity | Address-based authorisation | Authorised address list |
| Connectivity | Destination policy, deny by default | Policy record and change history |
| Control | Role-based administration | Access log, periodic review record |
| Control | Recording access and retention | Access log, retention configuration |
| Numbering | Presentation authority | Authority evidence per range |
| Numbering | Port-out verification | Authorisation record |
| Operation | Change attribution | Before and after state per change |
Yes, where an endpoint genuinely cannot support something. It becomes a recorded exception attributable to a named person and is revisited at the next review rather than becoming permanent by inattention.
This site makes no certification or accreditation claim. If a specific standard matters to your procurement, ask and you will get a precise written answer, including where that answer is no.
Where this is applied
Connectivity
The outermost layer. Whether a call can happen at all.
Open Layer twoControl
Where a call goes, and what happens when nobody answers.
Open Layer threeNumbering
What a caller dials, and whether it can ever be unreachable.
Open Layer fourOperation
Change, treated as a layer because it causes more incidents than failure does.
Open