Protocol Systems
ProtocolPlatform
A unified environment for managing security across people, properties, devices, identities, systems, and operations.
Product vision
What it is being built to do.
Most organizations and private clients manage security through a collection of disconnected tools. Access control lives in one system, identity in another, monitoring in a third, and the record of who decided what lives in email. Protocol Platform is being built as the layer that holds these together.
The design intent is a single environment where the people, places, systems, and decisions that make up a security posture are visible in one place, with a shared model of what is protected and who is responsible for it.
Problems addressed
The conditions it is designed for.
01
Security context is fragmented across vendors, tools, and inboxes.
02
No single view of what is protected, by which system, under whose responsibility.
03
Changes to access, staffing, or property are not reflected consistently across systems.
04
Decisions and their rationale are not recorded in a way that survives staff turnover.
Individually competent systems, procured at different times, produce a program whose weakest link is the space between them.
Core functions
Functions in development.
These describe design intent. Nothing listed here is available to purchase today, and the list will change as the product is built.
- 01Unified inventory of people, properties, devices, identities, and systems
- 02Role and responsibility mapping across internal teams and vendors
- 03Access and permission oversight across connected systems
- 04Security posture documentation and change history
- 05Assessment and remediation tracking
- 06Connections to Identity, Vault, Residence, and Command
Ecosystem connection
How it connects.
Platform is the foundation the other products connect to. Identity, Vault, Residence, and Command each own a domain; Platform holds the shared model of what exists and who is accountable for it.
No product in the Protocol ecosystem is designed to be bought alone. Each one owns a domain and reads from a shared record of what is protected and who is accountable for it.
Bought as products
- Each system holds its own model of the environment
- Alerts arrive in separate consoles with no shared priority
- Integration is attempted after procurement
- Nobody owns the boundaries between systems
Designed as a system
- One record of what exists and who is accountable
- Signals resolved against a shared priority
- Interfaces specified before anything is bought
- Every boundary has a named owner
Intended audiences
Who it is designed around.
The environments below shaped the design. A family office coordinating several households and a distributed enterprise are different problems, and a product that pretends otherwise serves neither.
Design discipline
Protocol builds against a described environment rather than a feature list. The constraint is the same one that governs a well-made instrument: every part has a reason, and nothing is added because it demonstrates well.
Protocol Platform is in development. Protocol is talking to the people it is being built for.
Adjacent systems
What it works alongside.
Conceptual interface
An interface study, not a screenshot.
The panel below is an abstract study of the product's structure, drawn from its own function names. No interface has been built and no data is represented.
Platform
- Unified inventory of people, properties, devices, identities, and systems
- Role and responsibility mapping across internal teams and vendors
- Access and permission oversight across connected systems
Related capabilities
The work this product supports.
Discuss this product.
Speak with Protocol about Protocol Platform — its development direction, the requirements it should meet, or the security program it would sit inside.