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
I architect the systems behind enterprise trust.
I turn security, AI and third-party risk requirements into decision-ready operating systems—controls, evidence, ownership, exceptions, remediation, monitoring and executive risk reporting. The result is governance work designed to withstand scrutiny and help the business move with confidence.
NIST AI RMFISO/IEC 27001SOC 2 TSCEU AI ActGDPR Art. 28
Open to high-ownership rolesTechnology GRC · TPRM · Security Compliance · AI Governance abdullahalowasi369@gmail.com
Operating portfolioEvidence-linked
10
governance systems architected
15
AI use cases mapped
25
buyer questions systematized
20
vendor-risk questions designed
Core operating logic
Requirement → control → evidence → exception → residual risk → decision.
01 / Executive value
Built for the decisions behind trust.
The portfolio is organized around the business problems a Technology GRC or AI Governance function is expected to solve: move diligence, strengthen assurance, govern AI risk and make third-party decisions defensible.
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
Built to operate, not decorate a résumé.
Capability is expressed through systems, artifacts, decision logic and implementation context. The emphasis is on what I can structure, analyze, build and defend in a real risk conversation.
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 + GRC systems
Systems Thinking
Automation & Technical SystemsTechnical foundation for decomposing governance problems into inputs, states, dependencies and decision logic.
Applied in · BSc Computer Science + operating portfolio
05 / Operating thesis
I think in systems, evidence and decisions.
My work sits where security, compliance, AI and business risk meet. I design governance structures that make ownership explicit, evidence inspectable, exceptions visible and residual risk useful to decision-makers.
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
BSc (Hons) Computer Science · SEGi University
Computer Science strengthens the systems side of my GRC work: data structures, software engineering, 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 / Hiring conversation
If the mandate is trust, risk or AI governance, bring me the hard problem.
I am targeting high-ownership roles across Technology GRC, Security Compliance, Third-Party Risk, Technology Risk and AI Governance. Send the role and the problem you need solved; the systems, artifacts and reasoning on this site make it easy to evaluate how I would approach the work.
Best-fit mandate
High-ownership Technology GRC & 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