Security Architecture & Advisory
Some vulnerabilities come back every quarter because the cause is a design decision, not a missing patch. I review the architecture behind the findings and help you decide what to change, in what order, and what it will cost to run.
Who this is for
- IT and security leads planning a change (a network redesign, a new identity provider, a logging platform) who want an independent review first.
- Teams whose vulnerability data keeps pointing at the same structural problems.
- Organizations without a senior security architect on staff who need one for a defined question.
- MSPs and vCISOs who want a second architect on a client review.
- Teams evaluating a new application or vendor who want security considered before it's bought and deployed, not after.
What a review covers
I review what's actually configured, not only the diagrams, using read-only access agreed in the rules of engagement.
- Segmentation. Which systems can reach which, whether that matches what the business needs, and where a flat network turns one finding into many.
- Identity. Admin accounts, service accounts, MFA coverage, and how privileged access is granted and removed.
- Logging. Whether the events you'd need after an incident are collected, kept and searchable, and who would look at them.
- Exposure and remote access. What faces the internet, what remote access paths exist, and which third parties can reach in.
- Cloud identity. Who and what can act in your cloud accounts, and how those permissions are granted and reviewed.
- New applications. For an application you're considering: how it fits into your network, what it needs access to, what data it handles, and what has to be in place before it goes live. I track it through each onboarding stage so security isn't left to the end.
Each finding is tied to a risk and a next step, with the trade-offs stated. I'll say when a change isn't worth its cost, and when a compensating control is the better answer for now.
How it connects to your vulnerability data
Where you already scan, I start from that data. Recurring findings, unreachable hosts and assets nobody owns are often the clearest signs of a design problem, and they give the review a measurable baseline. After the changes, the same data shows whether they worked.
Ways to engage
- Architecture review. A fixed-scope review of one environment or one planned change, with a written report.
- Application security review. A review of a new application or vendor, from evaluation through onboarding.
- Advisory hours. A block of time for design questions, vendor evaluations or reviewing your team's proposals.
- Fractional retainer. A standing monthly arrangement when you want the same second opinion available across several decisions. Scope and cadence are agreed up front.
Deliverables
A written review with prioritized actions, and decision records: what was decided, the options considered, and why. They're written so a future auditor or new hire can follow the reasoning. For a planned change, the review also lists what to verify once the change is live.
Timeline
A review's length depends on the environment and the question; the written scope gives the timeline. Advisory hours and retainers run on the cadence we agree.
Where this comes from
I've done architecture and security reviews for many organizations over the years. What I find most often: flat networks where one compromised host reaches everything, shared and over-privileged admin accounts, logging that wouldn't support an investigation, remote access nobody has inventoried, and new applications that went live before anyone asked how they fit.