Enterprise Security Architect

Enterprise Security Architect

When to Use

• Define enterprise security reference architecture — domains, layers, trust boundaries, patterns catalog
• Harmonize security domains — identity, data, application, network, endpoint, operations
• Design zero-trust and segmentation — identity-centric access, micro-segmentation, east-west controls
• Map control frameworks — NIST CSF, ISO 27001 Annex A, CIS, SOC 2 to architecture building blocks
• Integrate security with enterprise architecture (EA) — capability maps, standards, exception process
• Align architecture with risk appetite — control tiers, compensating controls, treatment themes
• Publish BU and acquisition standards — mandatory patterns, integration playbooks, sunset rules
• Run security architecture review — ARB criteria, threat-informed design gates, pattern exceptions
• Prepare architecture executive briefings — standards adoption, zero-trust roadmap, pattern gaps, acquisition integration (not CISO program KRIs)

When NOT to Use

• Multi-BU cloud landing zones, CCoE, EA commits, regulated cloud placement, cloud guardrail catalog → enterprise-cloud-architect
• Single-product or single-account cloud target design → cloud-architect
• Implement SCPs, CSPM rules, cloud IAM policies, KMS wiring → cloud-security-engineer
• Deploy SSO connectors, SIEM pipelines, EDR, hardening runbooks → information-security-engineer
• Build risk registers, inherent/residual scoring, FAIR estimates → security-risk-analyst
• Entitlement modeling, access reviews, PAM vault configuration → iam-specialist
• GRC program scope, audit prep, questionnaire packs → compliance-specialist
• Automate control evidence from IdP, CI/CD, CSPM → compliance-engineer
• CI SAST/SBOM, pipeline scan gates, artifact signing only → devsecops
• Security program strategy, policies, vuln/IR program, pentest governance → cybersecurity
• Board program briefings, risk appetite, KRIs, crisis comms → chief-information-security-officer
• Product/service ADRs, C4 models, strangler migrations → senior-system-architecture
• Infrastructure capex portfolio and facility supply chain → vp-of-infrastructure

Related skills

Core Workflows

1. Define scope and operating model

Clarify enterprise vs federated ownership, ARB authority, and mandatory vs recommended controls.

See `references/enterprise_security_architect_scope.md`.

2. Publish reference architecture

Layered model, domain map, pattern catalog, and integration points to EA.

See `references/security_reference_architecture.md`.

3. Design identity, data, and zero trust

Identity-centric access, data protection tiers, segmentation, and ZTNA/SASE alignment.

See `references/identity_data_and_zero_trust.md`.

4. Standardize application and integration security

Secure SDLC gates, API/B2B patterns, secrets, and third-party integration standards.

See `references/application_and_integration_security.md`.

5. Map governance, frameworks, and controls

Map frameworks to architecture blocks; define control tiers and exception lifecycle.

See `references/governance_frameworks_and_controls.md`.

6. Brief executives on architecture posture

Architecture packs for board/CISO: standards adoption, KPIs, investment cases, acquisition integration (program KRIs → chief-information-security-officer).

See `references/executive_security_architecture_briefings.md`.

7. Integrate acquisitions and new BUs

Apply assimilation playbook — identity, logging, segmentation, mandatory patterns by day 1/30/90.

See `references/enterprise_security_architect_scope.md` (M&A stakeholders) and `references/executive_security_architecture_briefings.md` (acquisition summaries).

Outputs

• Enterprise security reference architecture — domains, layers, trust zones, pattern catalog
• Zero-trust roadmap — phases, dependencies, identity and segmentation milestones
• Control-to-architecture matrix — framework clauses mapped to building blocks and evidence owners
• Security standards catalog — mandatory, recommended, deprecated; BU adoption checklist
• ARB/security review checklist — threat-informed gates, exception template with expiry
• Acquisition integration playbook — identity, logging, data, network assimilation steps
• Executive briefing deck outline — posture, top gaps, investments, measurable outcomes

Principles

• Architecture before tooling — patterns and control intent precede vendor selection
• Identity is the perimeter — authenticate, authorize, and continuously validate every access path
• Defense in depth by domain — no single control family carries the entire risk
• Measurable standards — every mandatory pattern has a validation method and owner
• Federation with guardrails — central standards, local delivery within approved patterns
• Risk-informed exceptions — time-bound, logged, tied to residual risk acceptance
• Patterns before implementation — information-security-engineer and cloud-security-engineer deploy; this skill defines intent and standards

Application and integration security

Table of contents

1. Secure SDLC gates 2. API and B2B integration 3. Secrets and configuration 4. Third-party and SaaS 5. Architecture review checklist

Secure SDLC gates

Define minimum gates by tier (coordinate implementation with devsecops):

Architecture owns what must be proven; engineering owns how in pipelines.

API and B2B integration

Document trust direction (inbound vs outbound), data classes carried, and failure modes (fail closed vs degraded).

Secrets and configuration

• Central secrets manager or vault; no long-lived credentials in config files
• Environment separation — prod secrets never in lower environments
• Rotation — documented cadence; emergency rotation playbooks
• Configuration drift — baseline images and policy-as-code preferred over manual prod edits

Third-party and SaaS

Align vendor tiers with compliance-specialist questionnaires; technical evidence with compliance-engineer where automated.

Architecture review checklist

Use in security ARB for new or materially changed systems:

1. Assets and data — tiers, residency, retention 2. Trust boundaries — diagrams with authN/authZ at each crossing 3. Identity — human vs machine; admin paths 4. Network — zones, ingress/egress, segmentation 5. Cryptography — algorithms, key management, TLS versions 6. Logging & monitoring — what events, where stored, retention 7. Availability & DR — RTO/RPO; security of backups 8. Dependencies — third parties, shared platforms 9. Threats — top abuse cases and mitigations 10. Exceptions — compensating controls, owner, expiry

Record outcomes in the architecture decision log; link product ADRs in senior-system-architecture when scope is a single product line.

Enterprise security architect scope

Table of contents

1. Role boundaries 2. Operating model 3. Stakeholders 4. Deliverable maturity

Role boundaries

vs enterprise-cloud-architect

enterprise-cloud-architect owns multi-BU cloud programs — landing zones, CCoE, enterprise agreements, regulated cloud placement, and hybrid integration at cloud-EA depth. This skill owns enterprise-wide security domains (identity, data, app, network, endpoint) and patterns that apply on-prem, SaaS, and cloud. Coordinate where cloud guardrails express security standards; do not duplicate landing-zone vending or FinOps commit strategy here.

vs information-security-engineer

information-security-engineer implements and operates controls — SSO connectors, KMS, WAF, SIEM/EDR pipelines, hardening baselines, remediation engineering. This skill defines what must exist (reference architecture, mandatory patterns, ARB gates) and hands off build/run to engineering. Do not author terraform modules, connector configs, or SOC playbooks in architecture deliverables.

Operating model

Define how security architecture governs the enterprise:

Recommended tiers for systems:

Stakeholders

Deliverable maturity

Track adoption metrics: % workloads on mandatory patterns, exception aging, time-to-approve architecture changes.

Executive security architecture briefings

Table of contents

1. Audience and cadence 2. Narrative structure 3. Investment framing 4. Acquisition summaries 5. Anti-patterns

Audience and cadence

Boundary: Program KRIs, risk appetite, crisis comms, and full board security narrative → chief-information-security-officer. This reference covers architecture evidence (reference model version, adoption metrics, zero-trust phases, exception register).

Keep technical depth in appendix; main deck is decision-oriented.

Narrative structure

Recommended flow (10–15 slides max for board):

1. Context — threat landscape headline (1 slide, sourced) 2. Posture snapshot — domains: identity, data, app, network, endpoint, ops (traffic-light) 3. Standards adoption — % mandatory pattern coverage; top gaps 4. Zero-trust / segmentation — phase, milestones, blockers 5. Material exceptions — count, aging, compensating controls summary 6. Incidents / lessons — architecture-relevant themes only (not SOC ticket detail) 7. Investments — prioritized initiatives with outcomes and dependencies 8. Acquisitions / major programs — integration status 9. Asks — decisions, funding, policy, or risk acceptance

Link each gap to a named initiative and owner; avoid orphan findings.

Investment framing

Coordinate infrastructure funding narratives with vp-of-infrastructure when initiatives span security and platform.

Acquisition summaries

One-page security integration status per deal:

Do not duplicate legal due diligence; flag architecture blockers for integration leadership.

Anti-patterns

• Tool laundry lists without control outcomes
• Heat maps with no owners or remediation dates
• Conflating risk score with architecture maturity (use both, label clearly)
• Promising zero trust completion without identity and logging prerequisites
• Board decks that are audit evidence dumps (route detail to compliance-specialist)

Pair narratives with architecture artifacts: reference model version, standards catalog revision, exception register excerpt.

Governance, frameworks, and controls

Table of contents

1. Framework mapping 2. Control tiers 3. Exception lifecycle 4. Risk and GRC interfaces 5. Metrics

Framework mapping

Map architecture building blocks to framework clauses (not a substitute for audit):

Control-to-architecture matrix columns:

Coordinate program scope and audit prep with compliance-specialist; automated evidence with compliance-engineer.

Control tiers

Examples of mandatory patterns: central SSO, no shared admin accounts, encrypted sensitive data at rest, security logging for T0/T1.

Exception lifecycle

1. Request — system, control gap, proposed compensating control 2. Risk assessment — inherent/residual input from security-risk-analyst 3. Approval — authority per tier (ARB lead, CISO delegate) 4. Conditions — expiry date, monitoring, remediation plan 5. Review — quarterly until closed or renewed with fresh risk acceptance

Never allow indefinite exceptions for mandatory controls without executive risk acceptance on record.

Risk and GRC interfaces

Architecture answers what good looks like; risk answers how much is enough; GRC answers what auditors need.

Metrics

Tie metrics to investment cases in executive briefings; avoid vanity counts without remediation owners.

Identity, data, and zero trust

Table of contents

1. Zero-trust principles 2. Identity architecture 3. Data protection tiers 4. Segmentation 5. Roadmap phases

Zero-trust principles

Apply consistently across corporate, cloud, and partner contexts:

1. Verify explicitly — authenticate and authorize every request; no implicit trust by network location 2. Least privilege — just-enough access with time bounds for privileged use 3. Assume breach — segment, log, detect lateral movement; limit blast radius 4. Continuous validation — device posture, session risk, step-up auth when signals change

Zero trust is a program, not a single product. Architecture defines required capabilities; iam-specialist and information-security-engineer implement.

Identity architecture

[ Human identities ] → IdP (SSO/MFA) → RBAC/ABAC → apps & infra
[ Machine identities ] → workload identity / SPIFFE-style → scoped credentials
[ Privileged access ] → PAM/JIT → session monitoring → break-glass (rare, audited)
[ Customer identities ] → separate CIAM stack where applicable

Coordinate detailed entitlement design with iam-specialist; cloud IAM policy patterns with cloud-security-engineer where applicable.

Data protection tiers

For each tier document: encryption (at rest/in transit), key custody, retention, residency, and logging requirements.

Segmentation

Avoid flat networks with shared admin paths. Document allowed flows (who talks to whom, on which ports, with which identity).

Roadmap phases

Publish dependencies (e.g., IdP before app segmentation) and metrics per phase for executive tracking.

Security reference architecture

Table of contents

1. Layered model 2. Security domains 3. Trust zones 4. Pattern catalog 5. EA integration

Layered model

Use a consistent stack when describing any system:

[ Business context & data classification ]
[ Applications & APIs ]
[ Identity & access ]
[ Data protection & key management ]
[ Network & segmentation ]
[ Endpoint & workload ]
[ Security operations & visibility ]
[ Governance, risk, compliance hooks ]

Each layer lists required controls, approved patterns, and telemetry expected downstream.

Security domains

Document interfaces between domains (e.g., identity signals feeding network policy).

Trust zones

Map each workload to one primary zone; document cross-zone flows explicitly.

Pattern catalog

Maintain enterprise patterns with ID, intent, prerequisites, and anti-patterns:

Each pattern links to validation tests (design review questions or automated checks).

EA integration

Align security architecture to enterprise architecture artifacts:

1. Map patterns to business capabilities and application portfolios 2. Publish technology standards (approved, conditional, prohibited) 3. Feed technology radar — emerging controls (ZTNA, SSE, confidential computing) 4. Coordinate migration waves — security gates per wave, not bolt-on at cutover 5. Maintain decision log — exceptions, expiry, compensating controls

For cloud-specific placement and landing zones, coordinate with enterprise-cloud-architect; this reference stays technology-agnostic where possible.