Why Saudi Insurers Replace Their Core Policy-Administration Systems More Often Than Banks Replace Core Banking Platforms: The Three Legacy-Architecture Patterns That Raise SAMA CSF Domain 1 Remediation Cost by 200%
When transformation leads at Saudi insurance companies plan core-system modernisation, they face a question that their counterparts in banking rarely encounter: can we bring this platform into compliance with the Saudi Central Bank's Cyber Security Framework, or must we replace it entirely? The answer usually depends on three architectural decisions made decades ago, long before the regulator expected insurers to demonstrate role-based access control, comprehensive audit trails and formal change-management workflows. These SAMA CSF insurance sector challenges are not theoretical; they determine whether Domain 1 remediation is a six-month project or a three-year platform replacement.
The difference in replacement frequency is visible across the Kingdom. Banks running core banking platforms from the 1990s often remediate them successfully for SAMA CSF compliance, while insurers running policy-administration systems from the same era find remediation cost exceeds replacement cost. The root cause is not the age of the platform but the way business logic, security rules and integration points were originally designed.
The Three Legacy-Architecture Patterns That Drive Remediation Cost
Pattern One: Business Logic Embedded in Stored Procedures
Many policy-administration platforms built in the 1990s and early 2000s implemented underwriting rules, premium calculations and claims-adjudication logic directly in database stored procedures. The application tier was thin—often a presentation layer only—and the database became the engine for policy lifecycle management.
This architecture creates three specific obstacles to SAMA CSF Domain 1 compliance.
First, role-based access control becomes unworkable. The Saudi Central Bank expects insurers to enforce separation of duties: the employee who underwrites a policy should not also approve the claim, and the developer who writes code should not deploy it to production. When business logic lives in stored procedures, database administrators hold both development and production privileges by necessity. Splitting these roles requires rewriting the logic into application code, adding a service layer and restricting database access to data operations only.
Second, audit trails are incomplete. SAMA CSF Domain 1 requires a record of who changed what, when and why. Stored procedures execute under the application's service account, not the end user's identity. The database logs show that the service account updated a record, but not which underwriter made the decision or which manager approved the exception. Retrofitting user-level audit trails into stored-procedure logic requires either rewriting every procedure to accept and log a user identifier, or migrating the logic to an application layer that already tracks session context.
Third, change management cannot meet the framework's expectations. The regulator expects insurers to test changes in a non-production environment, document the business justification, obtain approval and deploy through a controlled release process. Stored procedures are often edited directly in production by database administrators responding to urgent business requests. Version control is absent, rollback is manual and the approval trail exists only in email. Bringing this practice into compliance means treating stored procedures as application code: source control, peer review, automated testing and deployment pipelines. For platforms with hundreds of procedures and no existing DevOps tooling, the cost is prohibitive.
Pattern Two: Absence of API Layers and Hard-Coded Integration Points
Legacy policy-administration systems were built when integration meant batch file transfers and direct database connections. Reinsurance submissions, claims notifications to third-party administrators and premium collection from corporate clients all relied on scheduled jobs that read from or wrote to the core database, often using shared credentials with broad permissions.
SAMA CSF Domain 1 expects insurers to control access to sensitive data through defined interfaces, enforce least privilege and log every access request. Hard-coded database integration fails all three tests.
When a third-party administrator connects directly to the claims table to retrieve daily settlement files, the connection uses a database account with read access to the entire claims schema. There is no mechanism to restrict access to specific policy types, date ranges or customer segments. The audit log shows a login and a query, but not which business process triggered the request or which individual at the third party initiated it.
Remediation requires building an API layer: a set of services that expose only the data and operations each external party needs, authenticate every request, enforce entitlements and log the business context. For a platform with a dozen integration points, this is manageable. For a platform with fifty integration points—many undocumented, some supporting legacy products no longer sold but still in run-off—the effort rivals a full re-platforming.
The absence of APIs also blocks modern security controls. Multi-factor authentication, token-based access and dynamic entitlements all assume requests pass through an application layer that can enforce policy. Direct database connections bypass these controls entirely.
Pattern Three: Security Rules Hard-Coded in Application Logic
Early policy-administration platforms implemented security by embedding permission checks in application code: "If user is in group Underwriters, show the Approve button; otherwise hide it." These rules were written once, compiled into the application and rarely revisited.
SAMA CSF Domain 1 requires role definitions to be centrally managed, auditable and adaptable to organizational change. Hard-coded security rules fail on all counts.
When an insurer reorganizes its underwriting department—splitting motor and property into separate teams with different approval limits—the change requires modifying application code, recompiling, testing and deploying a new release. The alternative is to grant both teams the same broad permissions and rely on procedural controls, which the regulator does not accept as equivalent to technical enforcement.
Audit and compliance teams cannot answer basic questions: which roles can approve policies above a certain sum insured? Which users can override a fraud alert? The answers are scattered across source code, and extracting them requires a developer to search the codebase.
Remediation means externalizing security rules into a policy engine or identity-management platform, then refactoring the application to call that engine for every access decision. For a monolithic application with security checks in hundreds of code paths, the refactoring is extensive and error-prone.
Why Banking Platforms Avoid These Patterns
Core banking platforms from the same era often avoided these three patterns because banking regulators imposed stricter audit and control requirements earlier. By the time policy-administration systems were being built, banks were already separating business logic from database logic, implementing service-oriented architectures for integration and externalizing security into directory services.
The result is that a bank planning SAMA CSF remediation can often add API gateways, enhance logging and integrate with a modern identity platform without rewriting the core. An insurer with a legacy policy-administration system must choose between a costly, multi-year remediation that touches every layer of the platform, or replacement.
The Cost Calculus for Transformation Leads
When transformation leads at Saudi insurers evaluate their options, they compare the cost of remediating the legacy platform against the cost of replacing it with a modern policy-administration system that is built for API-first integration, externalized security and comprehensive audit logging.
Remediation cost includes the technical work—rewriting stored procedures, building APIs, refactoring security—and the operational risk. The platform remains in production throughout the remediation, and each change introduces the possibility of a defect that disrupts underwriting or claims processing. Testing is complicated by the lack of automated test suites, and rollback is difficult when changes span database schema, application code and integration endpoints.
Replacement cost includes licensing, implementation and data migration, but the new platform starts with an architecture that supports SAMA CSF Domain 1 requirements natively. Role-based access control, audit trails and change management are configurable, not custom-built.
The calculus tips toward replacement when the legacy platform also carries other technical debt: unsupported operating systems, databases nearing end-of-life or integration points that rely on protocols no longer considered secure.
Preparing for SAMA CSF Assessment Regardless of Platform Choice
Whether an insurer chooses remediation or replacement, the first step is the same: a maturity assessment against the SAMA Cyber Security Framework that identifies which controls the current platform cannot meet and why.
From maturity assessment to a defensible position with SAMA, the process includes an evidence-based maturity rating for every control, gaps prioritized by risk, effort and regulatory weight, and practical remediation support, not just a report. The assessment produces a maturity assessment report by domain and control, a gap analysis and prioritized remediation roadmap, updated policies, standards and procedures, an evidence pack and index, and an executive summary for the board. An evidence pack organized for reviewers ensures the institution is ready for follow-up and re-assessment.
The assessment typically requires six to ten weeks; remediation duration depends on the roadmap and the platform architecture. The engagement works from the current published framework and any circulars that apply to the institution at the time of the engagement.
For insurers with legacy policy-administration systems, the assessment often reveals that Domain 1 gaps—cybersecurity governance, role separation, audit trails and change management—are not policy gaps but architecture gaps. That finding changes the conversation from compliance to transformation, and gives the board the evidence it needs to make an informed decision about the platform's future.
