Why This Role: Security governance is currently squeezed into regular domain reviews. Security requirements are reactive ("add security to the design") rather than proactive ("here are the security standards, build against them"). Payment Card Industry Data Security Standard (PCI-DSS), Anti-Money Laundering (AML), and banking secrecy regulations require dedicated security governance. This role ensures security standards are published upfront, embedded in reference architectures, and consistently applied across all designs.
Responsibilities:
+ Security Reference Architectures: Develop and maintain reference architectures for each domain that embed security controls (authentication, authorization, encryption, audit, secrets management). SAs use these as starting points, not as afterthought add-ons.
+ Security Standards & Checklists: Publish domain-specific security checklists (e.g., "Building a microservice in Domain 5? Here are the 12 required security controls"). Tier 1 self-approval checklists include security checklist items.
+ Security Review in Tier 2/Tier 3: Participate in Tier 2 reviews (with Domain EA) and Tier 3 reviews (with ARB) to assess architectural security. This is dialogue, not veto - Security Lead and Domain Lead solve design problems together.
+ Threat Modeling: Conduct threat modeling workshops for high-risk designs (Tier 3, or any design involving payment/regulatory data). Use STRIDE or similar framework. Document threats and mitigations in the architecture decision record.
+ Security Policy Development: Work with Compliance, Risk, and IT Security teams to translate regulatory requirements (SBV banking secrecy, PCI-DSS, AML) into architectural policies and standards.
+ Third-Party Security Assessment: Lead security architecture assessments for new vendors, cloud platforms, or technology selections. Provide security evaluation input to PoC process (works with Emerging Tech Lead).
+ ARB Participation: Attend every ARB meeting to present security architecture updates, discuss security review findings, and provide security perspective on high-complexity designs.
+ Incident Root-Cause Liaison: When security incidents occur, work with IR team to identify whether the root cause was an architectural control gap. Feed findings back into reference architecture updates.
Success Metrics (6-month review):Security reference architectures developed for 2-3 high-risk domains (Domain 1, Domain 4, Domain 5)Security checklists published and integrated into Tier 1 self-approval workflow% of Tier 2/Tier 3 designs with documented threat modeling: 100% (for high-risk designs)Spot-check audits find security control compliance: 95%+No post-implementation security architecture gaps discovered in spot-check audits
