Fragmented workflows
Risk exception processes were only partially managed through iInsight, while other steps continued over email.
Bringing vulnerabilitymanagement into oneunified platform.
Improving the end-to-end lifecycle of vulnerability and risk exception management through a bank-wide enterprise application.
01 / OVERVIEWOne platform.
One platform.
An entire lifecycle.
iInsight is an enterprise application used by security teams and application owners across a large banking organisation.
It manages the lifecycle of security vulnerabilities, from initial reporting and assessment to remediation, validation and final closure. It also supports risk and policy exception requests.
The objective of Phase 2 was to bring fragmented processes into a unified workflow, making the journey more structured, traceable and consistent.
PRODUCTiInsight
SCOPEBank-wide application
USERSSecurity teams & application owners
MY ROLEProduct execution & enhancements
02 / THE CHALLENGEA fragmented process
01 02 03
A fragmented process
needed a unified experience.
Disconnected lifecycle
Vulnerability reporting, assessment, remediation and validation needed to operate as a connected journey.
Different stakeholder needs
Security teams had different checklists, assessment parameters and requirements that needed to work within a common platform.
From partial digitisation
to end-to-end management.
PHASE 01INITIAL STATE
Risk exceptions
The initial platform supported risk-based exception management, but the process was only partially digitised.
Risk exception raised
Partial processing in iInsight
Remaining steps over email
Limited workflow coverage
PHASE 02EXPANDED SCOPE
Unified lifecycle management
Vulnerability management and the complete risk exception journey were brought into the platform.
Reporting & submission
Assessment & ownership
UAT remediation & validation
Production fix & closure
End-to-end workflow coverage
04 / HOW THE PRODUCT WORKSThe vulnerability
The vulnerability
management lifecycle.
A vulnerability moves through multiple roles and approval stages before the production fix is accepted and the issue is closed.
01
TESTER
Vulnerability submission
The tester raises a vulnerability in iInsight. The risk module classifies its severity as low, medium or high, with corresponding tags.
↓
02
CHECKER
Initial approval
The checker reviews and approves the submission. An assessment is then created and routed to the application owner.
↓
03
APPLICATION OWNER
UAT remediation
The application owner works on the remediation and submits the UAT fix for validation.
↓
04
TESTER + CHECKER
UAT validation and approval
The tester validates the UAT fix. After tester approval, the checker reviews and approves it. The approved fix is routed back to the application owner.
↓
05
APPLICATION OWNER
Production implementation
The application owner implements the approved remediation in production and submits the production fix.
↓
06
TESTER + CHECKER
Production validation
The tester validates the production fix, followed by checker approval.
↓
07
APPLICATION OWNER
Final approval and closure
The final approval is communicated to the application owner team, completing the remediation journey.
↗
Exception management is also integrated.
Application owners can initiate policy or risk-based exception requests directly through the iInsight portal.
Driving product execution
beyond the initial release.
I joined after the initial requirements for the platform had been established. My contribution focused on Phase 2 revisions, deployment and continuous improvements after rollout.
Requirement alignment
Worked with different security teams to understand their checklists, assessment parameters and workflow-specific requirements.
Workflow improvements
Managed revisions to workflows and addressed functional gaps and user-reported issues following the Phase 2 rollout.
UAT & release validation
Coordinated testing, validation and production readiness across engineering, security and infrastructure teams.
Cross-functional coordination
Helped align stakeholders around a common platform experience while accommodating different security-team use cases.
06 / IMPLEMENTATION CHALLENGEStandardising complexity
Standardising complexity
without losing flexibility.
Different security teams had different ways of assessing vulnerabilities and exceptions.
For example, the ASLC team had its own checklist and parameters, while the Cloud Security team required a different set of information.
The challenge was to consolidate these needs into common templates and workflows without making the platform unsuitable for individual teams.
THE PRODUCT APPROACHCommon foundation.
Common foundation.
Team-specific requirements.
Align the shared workflow and structure while accounting for the different information and validation needs of each security team.
What this experience
taught me about products.
01Enterprise products need to accommodate multiple stakeholders without fragmenting the core experience.
02Standardisation is not about making every team work identically. It is about creating a common structure that supports different needs.
03Product ownership continues after launch through feedback, workflow improvements and release validation.