Samuel Mfinanga · Named engineer · 20+ years infrastructure
Shape the first conversation
Start with the decision in front of you.
Answer what you know; every question is optional. Your choices prepare an editable brief, not a price or a delivery promise. Only these fixed choices travel to Contact; do not enter private records here.
An incident-response handoff scoped to the operating team
Zero-Trust Security: what this includes
Zero-Trust Security: the work in scope.
01What this isArchitecture and access review. The written scope identifies resources, identities, device context, priority changes, and the team that handles an incident.
02What you leave withThe agreed review outputs and, for changes actually implemented, a record of what changed and how it was validated. The proposal should say what remains for a later phase.
Zero-Trust Security: the practical distinction
What changes when this work is done here.
A security product you log into.
A resource-first plan, with changes scoped before they begin.
A report, and the same doors left open.
Prioritized changes with owners and a way to validate each one.
The workflow
How an access change gets scoped
01The mapWho can reach what today. Staff, admins, vendors, and the network.
02The cutName the change owner, affected users, validation, and rollback. Implementation follows an approved scope; segmentation is considered where the resource needs it.
03The watchReview relevant device posture and access evidence. Define who receives an incident handoff; ongoing monitoring is a separate scope decision.
04The proofFor work performed, document what changed and how it was checked. This is scoped architecture and labor, not a security app seat.
Start with the access problem
Four doors worth checking first.
A security review should start with a resource and the people or systems that need it. These are scoping paths, not a claim that every control or service is included.
01
Staff and administrator access
Who can still enter after a role changes or an employee leaves?
Bring to the conversation
Bring identity providers, privileged accounts, joiner/leaver steps, and the person who approves access.
Ask to see in the scope
Ask for an account inventory, access decisions, exceptions, and a way to check that removal worked.
02
Vendors and remote work
Which outside people and devices can reach a business-critical system?
Bring to the conversation
Identify vendors, remote entry points, device ownership, contract end dates, and the resource each party needs.
Ask to see in the scope
Ask for time-bounded access rules, device checks where applicable, and a record of who can revoke access.
03
Applications and sensitive data
Can one approved login reach more than its job requires?
Bring to the conversation
Name critical applications, data owners, service accounts, and the flows between on-site and cloud systems.
Ask to see in the scope
Ask for a resource-and-flow map, proposed policy changes, and validation before old paths are removed.
04
Incident containment
Who can stop a compromised account or device without improvising?
Bring to the conversation
Bring the current incident contacts, logging sources, authority to isolate, and continuity constraints.
Ask to see in the scope
Ask for an escalation and evidence-preservation handoff that can be exercised with the operating team.
Zero trust is not a product box or a promise that no breach can happen. The starting point is which people and devices can reach which resources—and why.
01
The critical resources
Name the systems and data that matter most, including remote access, vendor connections, and service accounts. Unknown owners are part of the finding.
02
The identity path
Review how staff, administrators, and vendors authenticate, how devices are assessed, and how access changes when a role or contract ends.
03
The existing controls
Inventory the identity, endpoint, network, application, and data controls already in place. A plan should say what can be reused before proposing another tool.
04
The change boundary
Agree which resource to protect first, who may approve a policy change, how users will be affected, and what reverses a failed cutover.
05
The response path
Identify who can isolate an account or device, who must be notified, and what evidence the organization needs to preserve during an incident.
What gets scoped
The review defines an access map, priority changes, implementation responsibilities, and incident-response handoff. Compliance claims and managed monitoring require separate evidence and scope.
These sources help frame the questions. They are not a LUCA certification or a promise that every control is included in a service quote.
Before you choose
Questions worth settling before you switch.
Is zero trust a product we have to buy?
No single product establishes zero trust. It is an approach to deciding access to specific resources using identity, device, and other relevant context. A written review should identify controls you already own and any gaps before recommending purchases.
Do we need to replace our network first?
Not necessarily. Start with the resources and access paths that matter most. The assessment should show where existing identity, device, and network controls can be used and where a separate infrastructure project is needed.
What should we receive from a security review?
Define the output before work starts: the resources in scope, current access paths, prioritized risks, proposed changes, owners, validation steps, and exclusions. Implementation and ongoing monitoring are separate scope decisions.
Will this make us compliant or prevent a breach?
No architecture can promise either outcome. Regulatory applicability, control testing, incident response, and any formal compliance opinion require their own scope and evidence. The review is a starting point for decisions, not a certification.
How do we avoid locking people out during the change?
Choose a limited first resource, identify affected users and an approval owner, test the new policy, and document the rollback before removing an old path. The actual sequence depends on your environment and written scope.
How we quote
Scope
Quoted per scope
For
Security-aware technology and compliance owners — identity-centric architecture, not bolt-on AV.
