Customer trust
Revenue-sensitive assurance
Turn recurring security and compliance questions into governed, evidence-backed answers designed to keep enterprise diligence moving without unsupported claims.
Operating across:
enterprise assurance
Md. Abdullah Al Owasi · Technology Risk & AI Governance Architect
I architect governance systems that turn risk into decisions.
I build the operating infrastructure behind enterprise trust: controls, evidence lineage, ownership, exceptions, remediation, monitoring and residual-risk decisions. The architecture is designed to help security, risk, legal and business stakeholders move faster without weakening defensibility.
NIST AI RMFISO/IEC 27001SOC 2 TSCEU AI ActGDPR Art. 28
Open to high-ownership mandatesTechnology GRC · TPRM · Security Compliance · AI Governance abdullahalowasi369@gmail.com
Operating portfolioEvidence-linked
10
governance systems designed from requirement to decision
15
AI use cases mapped across risk, oversight and transparency
25
buyer-diligence questions linked to evidence paths
20
vendor-risk questions structured for criticality and evidence
Core operating logic
Requirement → control → evidence → exception → residual risk → decision.
01 / Executive value
Built for the decisions behind trust.
The architecture is organized around four enterprise outcomes: move customer diligence with defensible evidence, strengthen control assurance, govern AI risk as an operating discipline, and make third-party decisions proportionate to business exposure.
Control assurance
Audit-ready evidence operations
Connect controls to evidence owners, cadence, test logic, exceptions, remediation and retesting so assurance work has a repeatable operating structure.
AI risk
Decision-grade AI governance
Translate AI inventories into accountable risk decisions: purpose, data, human oversight, evaluation, monitoring, residual risk and transparency actions.
TPRM
Risk-based third-party governance
Prioritize vendor scrutiny by criticality, evidence quality, data exposure, contractual obligations and residual risk—not questionnaire volume alone.
Decision architecture
Governance should end in a decision—not a spreadsheet.
Requirement
Control
Evidence
Exception
Residual risk
Decision
02 / Flagship architecture
One evidence architecture. Three enterprise risk surfaces.
Customer assurance, third-party risk and AI governance are treated as connected operating problems. Each layer follows the same discipline: requirement → control → evidence → exception → residual risk → decision.
Integrated modules
Layer 01 · Control & evidence architecture
Enterprise Assurance Evidence Fabric
A control-to-evidence architecture that decomposes broad trust claims into accountable owners, reviewable evidence, framework references, exceptions and remediation decisions.
15
Evidence domains
SOC 2 + ISO
Primary lenses
Traceable
Operating model
Evidence preview
Illustrative architecture view| Domain | Decision question | Evidence path | Priority |
|---|---|---|---|
| Access | Can privileged access be defended? | RBAC · MFA · access review | High |
| Encryption | Is customer data protected in transit and at rest? | TLS · storage · KMS evidence | High |
| Incident | Can escalation and notification be evidenced? | IR plan · exercise · notice flow | High |
| Assurance | What independent or internal evidence supports the claim? | SOC scope · ISO evidence · control record | High |
Evidence owner
Review cadence
Framework crosswalk
Exception state
Remediation owner
03 / Selected decision systems
Governance systems built for scrutiny.
Ten systems spanning assurance, AI governance, third-party risk, audit operations and executive risk. Each is designed around the same standard: explicit ownership, traceable evidence, visible exceptions and a decision at the end.
Filter
04 / Capability architecture
Capability expressed as operating architecture.
Each capability is tied to a system, artifact, control model or decision structure so reviewers can evaluate the work rather than rely on self-rated proficiency.
Technology GRC
GRC & ComplianceRisk, controls, evidence, ownership, exceptions, remediation and assurance workflows.
Applied in · 10-system operating portfolio
SOC 2
GRC & ComplianceTrust Services Criteria translated into control, evidence, testing and assurance structures.
Applied in · 15-domain control inventory
ISO/IEC 27001
GRC & ComplianceISMS control architecture, risk treatment, ownership and evidence mapping.
Applied in · Control-to-evidence architecture
Security Questionnaires
GRC & ComplianceGoverned buyer answers with evidence paths, accountable owners and review cadence.
Applied in · 25-question assurance knowledge base
Control Testing
GRC & CompliancePopulation/sample logic, expected results, exceptions, remediation and retesting.
Applied in · Audit-operations system
NIST AI RMF
AI GovernanceGovern, Map, Measure and Manage applied to enterprise AI inventory and risk decisions.
Applied in · 15-use-case AI governance register
EU AI Act Article 50
AI GovernanceProvider/deployer transparency analysis for interactive and synthetic AI use cases.
Applied in · 15-use-case transparency register
ISO/IEC 42001
AI GovernanceAI management-system concepts integrated with accountability, risk and evidence workflows.
Applied in · AI governance operating architecture
AI Risk Registers
AI GovernancePurpose, data, stakeholder, oversight, evaluation, monitoring and residual-risk mapping.
Applied in · AI governance decision register
Shadow AI Governance
AI GovernanceApproved channels, prompt classification, secret detection, redaction and unsanctioned-use controls.
Applied in · 12-control governance standard
Third-Party Risk
TPRM & RiskCriticality tiering, evidence review, contractual risk, findings and treatment decisions.
Applied in · 10-vendor TPRM register
GDPR Article 28
TPRM & RiskProcessor instructions, subprocessors, assistance, deletion, audit rights and evidence requirements.
Applied in · 12-clause processor control set
Vendor Risk Assessments
TPRM & RiskEvidence requests spanning assurance, IAM, cryptography, privacy, resilience and AI providers.
Applied in · 20-question vendor-risk assessment
Executive Risk
TPRM & RiskLikelihood, impact, residual risk, appetite, treatment, KRI and escalation logic.
Applied in · 15-risk executive register
Python
Automation & Technical SystemsData transformation and repeatable artifact-generation workflows for governance and evidence operations.
Applied in · GRC evidence workbooks
TypeScript / React
Automation & Technical SystemsTyped interfaces for decision systems, interactive evidence views and portfolio tooling.
Applied in · This portfolio
Next.js App Router
Automation & Technical SystemsStatic-first web architecture, metadata, accessibility and deployment discipline.
Applied in · This portfolio
Git / GitHub
Automation & Technical SystemsVersion control, change traceability, repository documentation and delivery workflow.
Applied in · Portfolio repository
Data Modeling / SQL
Automation & Technical SystemsStructured thinking for evidence inventories, risk registers, ownership and relational decision data.
Applied in · Computer Science systems foundation + GRC systems
Systems Thinking
Automation & Technical SystemsTechnical foundation for decomposing governance problems into inputs, states, dependencies and decision logic.
Applied in · Computer Science systems foundation + operating portfolio
05 / Operating thesis
Governance is an operating discipline, not a documentation exercise.
My operating thesis is simple: every material requirement needs an accountable control, every control needs evidence, every exception needs treatment, and every residual risk needs a decision owner.
Operating principle
Evidence must survive challenge.
I design governance work so every important claim can be traced to a requirement, control, evidence path, accountable owner, exception state and decision. The objective is not documentation volume; it is decision quality under scrutiny.
Evidence architectureControl assuranceDecision quality
Enterprise assurance
Trust becomes valuable when it is operational.
Customer diligence, audits and executive risk reporting should draw from the same governed evidence system. That reduces contradiction, clarifies ownership and creates a cleaner path from security claim to business decision.
SOC 2ISO 27001Customer trust
AI governance
AI risk needs operating mechanics, not principles alone.
My AI governance work connects inventory, purpose, data, stakeholders, human oversight, evaluation, monitoring, transparency and residual risk so governance produces decisions rather than policy theatre.
NIST AI RMFEU AI ActISO 42001
Technical foundation
Computer Science · SEGi University
My computer science foundation strengthens the systems side of governance work: software engineering, data structures, databases, automation and disciplined decomposition of complex technical problems.
Computer ScienceSystems thinkingAutomation
06 / Framework depth
Standards translated into operating logic.
Framework knowledge matters when it changes how controls are designed, evidence is collected, ownership is assigned, exceptions are handled and decisions are made. These are the primary lenses behind the portfolio architecture.
Primary-source links are attached so the framework basis can be inspected directly.
Source-linkedAI risk management
Core operating lens
NIST AI RMF 1.0
Govern, Map, Measure and Manage provide the primary risk lifecycle used across the AI inventory, oversight, evaluation and monitoring architecture.
Applied in the architecture
GovernMapMeasureManage
Information security
Control architecture
ISO/IEC 27001:2022
ISMS requirements inform risk treatment, accountable control ownership, evidence structure and the relationship between governance intent and operating proof.
Applied in the architecture
ISMS contextRisk treatmentAnnex A
SOC 2 assurance
Assurance criteria
AICPA Trust Services Criteria
Security, availability, processing integrity, confidentiality and privacy criteria inform control-and-evidence structures used in customer assurance and audit operations.
Applied in the architecture
Common criteriaLogical accessChange management
AI transparency
Live transparency rule
EU AI Act · Article 50
Provider and deployer transparency obligations are translated into applicability, interaction disclosure, synthetic-content marking and communication decisions for relevant AI use cases.
Applied in the architecture
Interaction disclosureContent markingDeployer notice
Processor governance
Third-party control lens
GDPR · Article 28
Processor and subprocessor obligations drive DPA evidence requests, assistance duties, deletion/return controls, audit rights and vendor-governance decision points.
Applied in the architecture
Documented instructionsSubprocessorsAudit & deletion
AI management system
AI management lens
ISO/IEC 42001:2023
AI management-system concepts inform accountability, impact assessment, governance structure and continual-improvement patterns across the AI operating model.
Applied in the architecture
AI policyAccountabilityContinual improvement
07 / Executive conversation
Bring the governance problem that cannot stay ambiguous.
I am open to high-ownership opportunities across Technology Risk, GRC, Security Compliance, Third-Party Risk and AI Governance. Send the role, business context and hardest unresolved risk question. My portfolio shows the architecture and decision logic I would bring to the conversation.
Best-fit mandate
Technology Risk · GRC · TPRM · AI Governance
Control-to-evidence architecture · TPRM decisioning · AI risk operations
Kuala Lumpur, Malaysia · open to remote and relocation discussions
Executive portfolio binder, evidence workbook and resume available now