AiVRIC Secure Engineering & Architecture Foundations • Practitioner

Secure Engineering & Architecture

Secure engineering and architecture is the practice of translating governance expectations into design decisions, build requirements, review gates, evidence, and accountable remediation work. In CloudSignals+RiskOps, engineering teams can use the UCB control library, domains, principles, Assessment Objectives, evidence requirements, and RiskOps workflows to embed security and privacy into architecture and delivery.

Topic course: ~90 min • Certification path: 5–8 hrs 6 modules + capstone Intermediate to Advanced Certification eligible

Who this course is for

Security architects and cloud architects
DevSecOps and platform engineers
Application security teams
Engineering managers
Control owners responsible for technical implementation

Prerequisites

Basic knowledge of cloud architecture and software delivery
Familiarity with security controls and risk management
Access to Governance & Assurance and RiskOps project workflows

What you will be able to do

Translate UCB controls into secure engineering requirements.
Use domains and principles to explain why architecture controls exist.
Create evidence expectations for architecture and engineering controls.
Route design gaps into RiskOps projects and work items with owner, due date, and verification plan.
Manage secure change, exceptions, and compensating controls.
Use Vision to draft secure architecture narratives with human review and validation.

Platform areas used in this course: Governance & Assurance, Domain Explorer, Control Library, Program Builder, Evidence Fabric, RiskOps Projects, Request Hub, SLA Policies, Exceptions, Vision. Navigate to Governance & Assurance > Domain Explorer to begin.

AI advisory statement: Vision can explain architecture risks, summarize control requirements, and draft review narratives — but Vision should not approve architecture or certify compliance. All Vision outputs require human review, correction, and attestation before use as governance or audit evidence.

Secure Architecture Governance

15 min • Domain Explorer • Explain architecture control rationale

Controls are more effective when engineers understand why they exist

Secure architecture begins with principles. UCB domains and principles help explain control intent in business and technical terms — moving engineering teams from "the policy requires this" to "this control exists because..." Engineers who understand the rationale make better design tradeoffs, implement controls more accurately, and produce better-quality evidence.

Three examples of how UCB domain principles explain architecture requirements:

Identity controls

Exist to ensure only authorized identities can access the right resources at the right time. MFA, least-privilege, and service account scoping are implementations of this principle — not arbitrary security theater.

Data protection controls

Exist to maintain confidentiality, integrity, availability, retention, and privacy of information. Encryption at rest and in transit, key management, and data classification are implementations of this principle.

Cloud controls

Exist to reduce misconfiguration, exposure, privilege misuse, and unmanaged change in cloud environments. Network segmentation, public access blocks, and IaC security gates implement this principle.

In the platform — Lab 1 setup: Identify relevant domains for a system under review

Navigate to Governance & Assurance > Domain Explorer. Review the full domain list. For a current or planned engineering project, identify which domains are most relevant (e.g., Identity, Data Protection, Infrastructure Security, Cloud Security).

Click into the most relevant domain. Review the principles. For each principle, read the explanatory rationale — this is the "why" that engineers should internalize before designing controls.

Note which principles directly apply to your current engineering project. These become the anchor for your Module 2 control-to-requirement mapping exercise.

Select a current or planned system for this course's labs: All four labs build on one system. Choose something real — a new service, a planned migration, or a current architecture under review.

Map domains to your system: For your chosen system, list the 3–5 most relevant UCB domains. For each, note one principle that directly shapes a design decision you've made or should make.

Explain one control's rationale to your team: Using Domain Explorer, write a one-sentence explanation of why one UCB control exists — in terms your engineering team would find meaningful, not just policy language.

Knowledge Check

Why should secure architecture requirements be control-driven using the UCB rather than derived ad hoc from security team intuition?

Control-driven requirements are faster to document since they can be copied directly from the UCB without engineering interpretation.

UCB controls are source-attributed, testable, and connected to assessment objectives and evidence requirements — making control-driven architecture verifiable, consistent across teams, and traceable to governance obligations rather than individual security opinion.

UCB controls are required by law — organizations that don't use them face regulatory penalties for non-compliant architecture.

Control-driven architecture is only needed for externally-facing systems — internal services can use ad hoc security requirements.

Move on when you've mapped UCB domains to your chosen system and can explain one control's rationale.

Control-Driven Requirements

25 min • Control Library • Translate UCB controls into testable engineering requirements

The control-to-requirement translation workflow

Engineering teams should convert UCB controls into requirements that can be designed, implemented, tested, and evidenced. The translation has four steps: read the control expectation → write the engineering requirement → define the evidence → define the assurance test.

A worked example for the Data Protection domain:

Step	Content
Control expectation	Encrypt sensitive data at rest.
Engineering requirement	All production storage services containing regulated data must use AES-256 encryption with customer-managed keys stored in the approved KMS.
Evidence	Architecture diagram showing KMS integration, cloud configuration export confirming encryption settings, key management policy, deployment record, automated scan result passing the encryption check.
Assurance test	Verify encryption configuration on all in-scope storage services and confirm key ownership is in the designated KMS with rotation configured.

In the platform — Lab 1: Control-to-Requirement Mapping

Navigate to Governance & Assurance > Control Library. Select a technical control relevant to your system — ideally one in the domains you identified in Module 1.

Review the control's objective, purpose, guidance, and applicability dimensions. Note the Assessment Objectives — these are the testable assertions you'll need to satisfy.

Write three engineering requirements derived from this control. Each requirement should be specific enough that an engineer can implement it and a tester can verify it.

For each requirement, identify: what evidence will be collected to prove implementation? What automated check will verify it post-deployment?

Record your control-to-requirement mapping as your Lab 1 deliverable. Share it with your engineering team as the security requirements for this capability.

Complete a control-to-requirement mapping for your system: Translate at least 5 UCB controls into engineering requirements with evidence and assurance test definitions.

Identify pre-agreed evidence plans: For each requirement, document what evidence will be collected after deployment before implementation begins — not after.

Find one current gap: Using the Control Library, identify one UCB control that your current architecture does not yet satisfy. Add it to Module 4 work as a design gap to route into RiskOps.

Knowledge Check

Which of the following best represents a properly translated engineering requirement from a UCB control?

"Comply with the encryption at rest control per UCB Data Protection domain requirements."

"All production database instances in the payment processing environment must use AES-256 encryption with customer-managed keys in Azure Key Vault, with annual key rotation configured and verified by automated scan."

"Encryption is required. The engineering team should determine the appropriate implementation based on cloud provider guidance."

"The security team has reviewed this system and confirms encryption controls are in place."

Move on when you've produced a control-to-requirement mapping for your system with pre-agreed evidence plans.

Engineering Evidence

20 min • Evidence Fabric • Define and link architecture evidence to controls and AOs

Architecture evidence types

Architecture evidence is the documentation that proves design decisions were intentional, reviewed, and implemented as intended. Evidence must be mapped to controls and Assessment Objectives — not just stored as attachments. An architecture diagram sitting in a Confluence page that is not linked to a UCB control is reference material. The same diagram linked to a control in the Evidence Fabric, with a reviewer attestation, is governance evidence.

Valid types of engineering and architecture evidence include:

Design review records: documented security design reviews with findings, decisions, and named reviewer sign-offs
Architecture diagrams: approved data flow diagrams, component diagrams, and trust zone maps linked to specific controls
Threat models: structured threat analysis tied to specific architecture decisions and mitigations
Change approvals: records confirming that architecture changes were reviewed and approved before deployment
Deployment manifests: infrastructure-as-code or deployment records confirming the deployed state matches the approved design
CI/CD security gates: records showing security checks passed before deployment was permitted
Infrastructure-as-code reviews: scan results and peer review records for IaC security quality
Configuration exports: cloud provider configuration snapshots confirming control states post-deployment
Test results: security test reports confirming that implemented controls work as designed
Exception approvals: records of formally approved exceptions to control requirements, with compensating control documentation

In the platform — Lab 2: Architecture Evidence Package

Navigate to Governance & Assurance > Evidence Fabric. Identify the UCB controls for your system from Module 2. For each, review whether any evidence artifacts already exist and are linked.

For controls lacking linked evidence, define the required artifact types from the list above. Document this as an architecture evidence checklist — the expected artifacts for each control before this system is considered governance-ready.

Upload one available evidence artifact (architecture diagram, design review record, or configuration export). Link it to the relevant UCB control and Assessment Objective. Set evidence type, timestamp, and assign a reviewer.

Identify any missing evidence — artifacts in your list with no current artifact available. These are engineering evidence gaps to route into RiskOps in Module 4.

Build an architecture evidence checklist: For your system, list every expected evidence artifact type per UCB control. Mark what exists, what is partially complete, and what is missing.

Link at least one artifact to a control and AO: Upload or link an existing artifact, set its metadata, and assign a reviewer. Observe the AO confidence change after reviewer attestation.

List evidence gaps: Document which artifacts are missing for your system. This list becomes the input for your Module 4 RiskOps design gap routing.

Knowledge Check

Name four types of valid architecture and engineering evidence that can be linked to UCB controls.

Sprint velocity data, team capacity reports, code coverage metrics, and deployment frequency statistics.

Architecture diagrams (approved and control-linked), threat models, CI/CD security gate results, and configuration exports post-deployment — all mapped to specific UCB controls and Assessment Objectives with reviewer attestation.

Annual security training completion certificates, phishing simulation results, password policy screenshots, and endpoint compliance reports.

CVSS scores for open findings, MTTR measurements, pending decisions count, and risk pressure score trend data.

Move on when you've built your architecture evidence checklist and identified evidence gaps to route into RiskOps.

RiskOps Execution

25 min • Projects, Request Hub • Convert design gaps into accountable tracked work

From "we found a design gap" to accountable remediation

Secure engineering gaps become manageable when routed into accountable work. The goal of RiskOps execution for engineering teams is to move from the ambiguous state of "we found a design gap" to the governed state of "we have an owner, a due date, a risk rationale, an evidence expectation, and a verification plan." CloudSignals+RiskOps supports this through project creation, intake via the Request Hub, assignment, SLA policy enforcement, work item tracking, POA&M workflows, and recurring review schedules.

The Request Hub is how security teams submit design gap findings to the engineering intake queue — separating discovery (security) from triaging and planning (engineering lead). Each request in the hub becomes a tracked project or work item with governance metadata attached, not a Slack message that gets lost.

In the platform — Lab 3: RiskOps Design Gap

Take the evidence gaps and design weaknesses identified in Module 3. Navigate to RiskOps > Request Hub. Submit one design gap as a security request — include the UCB control it violates, the business risk rationale, and the suggested remediation approach.

Navigate to RiskOps > Projects. Create a project for the design gap. Set: project type (Security Remediation), linked UCB control, assigned owner (engineering lead), target date aligned to the relevant SLA policy.

Add work items to the project: specific implementation tasks, each with owner and due date. Include a verification work item — the step where the engineering team confirms the fix and collects evidence before the project is marked complete.

Navigate to RiskOps > SLA Policies. Confirm the project's target date is within the SLA window for this control's severity tier. If not, either escalate urgency or formally accept the SLA deviation with a risk rationale.

Draft a stakeholder communication explaining the design gap, the risk, what the team is doing about it, and by when. This is your Lab 3 deliverable: a secure engineering remediation plan.

Submit at least one design gap to the Request Hub: Every design gap identified in Module 3 should enter the governance system — not stay as an informal note or Jira backlog item without risk context.

Create a milestoned RiskOps project: For your primary design gap, create a project with work items, an owner per item, a verification task, and SLA-aligned target dates.

Confirm SLA alignment: Verify your project's target date is within the applicable SLA policy. Document any intentional SLA deviation with a formal risk acceptance.

Knowledge Check

How does routing design gaps into RiskOps improve secure engineering execution compared to tracking them in a team backlog?

RiskOps automatically generates Jira tickets for design gaps, eliminating manual tracking work for engineering teams.

RiskOps attaches owner accountability, SLA policy enforcement, UCB control linkage, evidence requirements, and verification criteria to each gap — converting informal intent into a formally governed commitment that auditors can inspect and executives can track.

RiskOps reduces the workload on engineering teams by automatically resolving low-severity design gaps without requiring manual remediation.

RiskOps is only required for design gaps on systems that handle regulated data — standard engineering systems can use team backlogs.

Move on when you've submitted a Request Hub entry and created a milestoned RiskOps project for your primary design gap.

Secure Change & Exceptions

20 min • Exceptions, SLA Policies • Govern deviations and approval workflows

When architecture decisions require exceptions

Some architecture decisions require exceptions — a legacy system that cannot meet a control, a vendor dependency that prevents full compliance, or a migration in flight that creates a temporary gap. An exception is not a governance failure; it is a governance decision. The failure mode is an undocumented exception — a gap that the team is aware of but that has not been formally acknowledged, risk-assessed, and approved.

A valid security exception for an architecture gap must include eight elements:

Scope: which control, system, asset, or environment the exception applies to
Reason: why the control cannot be implemented as required (with specificity)
Compensating controls: what alternative measures reduce the risk during the exception period
Residual risk: the risk that remains after compensating controls are applied
Approval: named approver with authority at the exception's risk tier
Expiration: a defined end date — exceptions must not be open-ended
Review cadence: when the exception will be formally re-evaluated
Linked evidence: proof that compensating controls are configured and operating

In the platform — Route an architecture exception through governance

Navigate to RiskOps > Exceptions (or Projects > Exceptions). Review existing exceptions — check age, expiry dates, whether all eight required elements are documented, and whether linked evidence exists.

Create a new exception for an architecture gap from Module 3 that cannot be immediately remediated. Fill in all eight required fields — do not skip compensating controls or residual risk.

Set the exception risk tier based on the linked control's severity. Higher-risk exceptions require higher-authority approvers. Confirm the routing is correct before submitting.

Navigate to RiskOps > SLA Policies. Review what SLA playbooks exist for recurring architecture risk types. Confirm any exception that introduces ongoing exposure is linked to an SLA policy that enforces resolution tracking.

Audit existing architecture exceptions: Confirm every exception has all eight required elements. Incomplete exceptions are governance liabilities, not governed risk.

Route one exception through governance: Submit a new exception with all eight elements, route it to the correct approver, and confirm the decision is recorded as a governance artifact.

Define your architecture change governance rule: Document which types of architecture changes require a UCB coverage review and findings check before deployment — share with your engineering leads.

Knowledge Check

What makes a security exception formally governed versus an informally acknowledged gap?

A formally governed exception has been discussed in a team meeting and logged in the team's issue tracker with a security label.

A formally governed exception has all eight required elements: scope, reason, compensating controls, residual risk, named approver, expiration date, review cadence, and linked evidence — all recorded in the governance system as an auditable artifact.

A formally governed exception has been approved by the CISO regardless of whether compensating controls or expiry dates are documented.

Exceptions become formally governed automatically after 90 days of inactivity — the platform marks them as accepted at that point.

Move on when you've routed at least one architecture exception through the full governance workflow.

AI-Assisted Design Review

15 min • Vision • Draft and validate secure design narratives with human review

What Vision can and cannot do in architecture review

Vision can help engineering teams with: explaining architecture risks in plain language, summarizing UCB control requirements for a specific domain, drafting security design review narratives, and identifying missing evidence based on the Evidence Fabric state. Vision should not approve architecture decisions or certify that a design is secure — those are human governance responsibilities requiring accountability.

The right workflow: Vision as first draft, engineer as reviewer and accountable author. When Vision drafts a secure architecture narrative, the responsible engineer reviews it for accuracy, corrects any mischaracterizations, adds context specific to the system, notes any assumptions Vision made that need verification, and attests to the narrative before it becomes a governance artifact.

In the platform — Lab 4 preparation: AI-assisted secure design narrative

Navigate to Vision > Ask Vision. Request a secure architecture review narrative for your system: "Draft a security design review summary covering identity, data protection, and cloud security controls for [describe your system type and environment]."

Review the output against your control-to-requirement mapping from Module 2. Does Vision correctly identify the relevant UCB controls? Are any requirements missing or mischaracterized?

Edit the narrative: correct inaccuracies, add system-specific context, note assumptions that need verification, flag any controls marked "satisfied" that still have open evidence gaps from Module 3.

Add your reviewer attestation and the required AI advisory disclaimer. Save the validated narrative to the Evidence Fabric linked to the relevant UCB controls. This completes your architecture evidence package.

Generate a Vision architecture narrative: Request a secure design review draft for your system. Verify all claimed control states against the Evidence Fabric before accepting any of the output.

Edit and attest the output: Correct mischaracterizations, add system context, and attach your reviewer attestation and AI disclaimer before saving to the Evidence Fabric.

Complete your architecture evidence package: Your system now has: control-to-requirement mapping (M2), evidence checklist with artifacts (M3), RiskOps project for gaps (M4), exception records (M5), and validated Vision narrative (M6).

Knowledge Check

What is the proper role of Vision in a secure architecture review?

Vision reviews and approves architecture designs against UCB controls, issuing a compliance certificate for designs that meet all control requirements.

Vision drafts first-pass architecture risk explanations, summarizes control requirements, and identifies possible evidence gaps — all requiring human review, correction, and attestation before the output becomes a governance artifact. Vision does not approve architecture or certify security.

Vision replaces the need for human security design review for low-risk systems, reserving human review for Critical and High risk architectures only.

Vision's role is limited to scanning IaC templates for known misconfigurations — it does not assist with narrative generation or architectural reasoning.

Move on when your architecture evidence package is complete: mapping, artifacts, RiskOps project, exception record, and attested Vision narrative.

Certification: AiVRIC Secure Engineering & Architecture Practitioner

Completing all six modules makes you eligible for the practitioner certification exam.

Exam domain	Weight
Secure architecture governance	20%
Control-to-requirement mapping	25%
Engineering evidence	20%
RiskOps execution	20%
Exceptions and AI-assisted review	15%

Capstone practical scenario

A new customer data platform is being deployed to cloud infrastructure. The design includes identity federation, production databases, CI/CD pipelines, third-party integrations, and AI-assisted analytics. Your task:

Identify relevant UCB domains and control principles for this system.
Convert the three most critical controls into testable engineering requirements with evidence definitions.
Define the evidence artifacts required for the architecture evidence package.
Identify design gaps and route them into RiskOps via the Request Hub with owner and SLA assignment.
Draft a secure architecture review narrative using Vision, then validate and attest it — including AI disclaimer.

Passing criteria: Uses UCB controls and principles as the design anchor. Produces specific, testable engineering requirements. Links evidence artifacts to Assessment Objectives. Routes unresolved gaps into accountable RiskOps work. Validates Vision output with human review — includes AI disclaimer and reviewer attestation on all AI-assisted content.

🏅

Course complete!

You've completed Secure Engineering & Architecture. Security requirements now flow from control intent through design to deployed evidence.

Next: Cloud Security