Amanda Walker
AW01 Security architect · Identity · Infrastructure · Emerging systems

Security architecture
that holds up in practice.

I build security architecture for systems that have to keep working after the meeting ends: access models, operational controls, audit evidence, and risk decisions.Personal working site. Open to full-time security architecture roles. View selected work.

Security takes judgement.

01

About

I did not come to architecture through diagrams. I came to it through systems already in motion: monitoring them, investigating failures, rebuilding controls, and learning what survives contact with operations.

I usually find the work where ownership is unclear, source data is imperfect, and technical decisions have become operational habits. I turn those conditions into choices people can explain, implement, test, and maintain.

Where I spend my time

  • Identity architecture
  • Certificate lifecycle
  • Data protection
  • Security automation

Emerging systems

AI raises familiar security questions in less familiar conditions: what the system is allowed to do, where its information comes from, and who is accountable for the outcome.

I notice when the workaround has become the architecture.

02

Selected Work

Rebuilding an Enterprise Identity Foundation

An identity platform became an operating model.

Capacity
Senior security engineer doing architecture work
Changed
Source of truth, directory integrations, policies, account management, onboarding, and entitlements
Proof
The platform became easier to use, operate, and audit
Context
I was brought in to make the organization’s identity platform work. That was the visible problem. The deeper problem was that the organization did not have a reliable picture of its own application environment, much less a mature identity architecture for governing it.
Problem
Teams were siloed, application ownership was often unclear, and the architecture had grown brittle through accumulated exceptions. Without a trustworthy source of truth or a consistent model for directory integration, policy, and lifecycle management, each new application risked adding a local solution to a systemic problem.
Approach

I began with application onboarding because it gave me a practical way into the system. Each integration exposed another part of the architecture that needed to be understood or rebuilt.

Over time, I reworked the source of truth, directory integrations, policy framework, account management experience, and application onboarding process. I also automated access entitlements and strengthened lifecycle management.

The work moved from solving individual integrations to building a repeatable identity model the organization could operate.

Outcome

The platform is now used, not merely deployed. Applications enter through a consistent process, entitlements are automated, lifecycle events are handled more reliably, and audit evidence is supported by coherent controls.

The organization also has a clearer understanding of its application environment and the relationships that govern access within it. Those outcomes did not come from the platform alone. They came from resolving assumptions the platform had previously been expected to absorb.

What I learned

Identity architecture is often as much about organizational clarity as it is about access. It forces decisions about authority, ownership, lifecycle, and exception.

When those decisions remain implicit, technology makes inconsistency faster. When they are explicit, automation reinforces the architecture instead of hiding its weaknesses.

Building Operational Visibility Under Pressure

Telemetry became usable visibility for critical care-delivery systems.

Capacity
Systems analyst building operational visibility
Changed
Critical application inventory, signal interpretation, dashboards, and alerting
Proof
The work was handed off and used in incident response to trace service degradation
Context
During COVID, telehealth applications became essential to care delivery. Traffic and service demand increased rapidly, while the availability and security of these systems carried greater consequence.
Problem

Logs were being collected, but collection had not become visibility. There was no agreed inventory of critical applications, no meaningful view of application health, and no clear way to distinguish normal activity from service degradation or a developing security concern.

The missing piece was not more data. It was a shared way to understand what the data meant.

Approach

I began with the telemetry because there was no reliable application inventory to begin from. I mapped the applications represented in the log data and determined which systems appeared critical to remote care.

I worked through the available signals to understand what they revealed about normal operation, degradation, failure, and possible security concerns. From that understanding, I built dashboards and alerting that turned raw logs into an operational view of application health.

Outcome

The dashboards and alerts gave monitoring teams a shared view of critical telehealth applications. During incident response calls, teams used them to trace service degradation, compare signals across the environment, understand the scope of an issue, and support escalation and remediation.

Once the capability was established, it was handed off to other monitoring teams across the organization. My team no longer operated it, but the work remained in active use.

What I learned

Observability is not simply a logging problem. It is a reasoning problem. Raw telemetry becomes useful only after someone determines which systems matter, what healthy behavior looks like, and what should trigger action.

I also learned that a capability is stronger when it can be handed off and operated without continued dependence on the team that created it.

03

Expertise

Security Architecture

Architecture and engineering that turn security decisions into systems teams can build, operate, and hand off.

Cloud & Infrastructure

Infrastructure reviewed through boundaries, dependencies, failure modes, and recovery paths. Not just whether the diagram is clean, but whether the system can be secured, operated, and recovered.

Identity & Trust

Access designed around how people actually join, move, leave, request exceptions, and inherit authority, including what breaks when the source data is wrong.

AI & Emerging Systems

Security for systems that retrieve context, make recommendations, or take action with less direct human involvement. The familiar questions still matter: what it can do, what it knows, where the data came from, and who owns the outcome.

04

Principles

Understand before intervening.

Start with the system as it exists: the dependencies, failure modes, ownership, exceptions, and assumptions already holding it together.

Make the tradeoff visible.

Every security decision moves cost, friction, risk, or responsibility. Make that movement explicit enough for people to choose it on purpose.

Design for the handoff.

A system is not finished when it works for the person who built it. It is finished when someone else can understand, operate, and maintain it.

Keep judgment close to consequence.

Automate what is repeatable. Keep human review where the decision is ambiguous, irreversible, or likely to affect people.

05

Contact

If the work resonates, a conversation is a good place to begin.