Trust operations
Customer assurance that can be defended
Structure security and compliance responses around approved evidence, accountable owners, review cadence and explicit exceptions so recurring diligence is consistent and inspectable.
Focused on
technology risk
Md. Abdullah Al Owasi · Technology Risk & AI Governance
Governance systems built to turn risk into decisions.
I design the operating logic behind technology risk, control assurance, third-party governance and AI risk: requirements, controls, evidence, ownership, exceptions, remediation, monitoring and residual-risk decisions. The portfolio is built so a reviewer can inspect how the reasoning works, not just read a list of frameworks.
NIST AI RMFISO/IEC 27001SOC 2 TSCISO/IEC 42001EU AI ActTPRM
Open to global opportunitiesTechnology GRC · Security Compliance · TPRM · AI Governance abdullahalowasi369@gmail.com
Evidence portfolioInspectable
10
governance systems designed from requirement to decision
15
AI use cases mapped across risk, oversight and transparency
25
buyer-diligence questions connected to evidence paths
20
vendor-risk questions structured for criticality and evidence
Signature operating model
Requirement → control → evidence → exception → residual risk → decision.
Business value
Built around the work global GRC teams actually own.
Customer assurance, control operations, technology risk, third-party governance and AI risk all converge on the same problem: turn requirements into evidence-backed decisions that technical and business stakeholders can act on.
GRC operations
Control assurance with an operating cadence
Connect control intent to evidence, testing, exceptions, remediation and retesting so assurance work can operate continuously instead of becoming a one-time audit exercise.
AI risk
AI governance tied to real decisions
Translate AI inventories into risk classification, ownership, human oversight, evaluation, monitoring and transparency decisions using NIST AI RMF, ISO/IEC 42001 and EU AI Act concepts.
TPRM
Third-party risk proportionate to exposure
Prioritize vendor scrutiny by criticality, data exposure, assurance evidence, processor obligations and residual risk rather than treating every questionnaire as equally material.
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
Selected systems
Governance systems a reviewer can interrogate.
Ten systems spanning assurance, technology risk, third-party risk and AI governance. Each shows the operating logic, evidence path, ownership model, exception state and decision structure behind the work.
Filter
Capabilities
Capabilities connected to evidence.
Each capability points to a system, artifact, control model or decision structure that can be inspected and discussed in a technical interview.
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 earns its value when it changes decisions.
My operating thesis is simple: material requirements need accountable controls; controls need evidence; exceptions need treatment; residual risk needs a decision owner. The portfolio applies that logic across assurance, third-party risk and AI governance.
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
Direct 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 · Security Compliance · TPRM · AI Governance
Control-to-evidence architecture · TPRM decisioning · AI risk operations
Kuala Lumpur, Malaysia · open to global remote and relocation discussions
Editable portfolio, ATS resume and evidence workbooks available now