Compliance and Security Considerations Building Insurance Tech

Building software for insurance is different from most other domains in a way that isn't always obvious until you're in it: the data itself is sensitive by default, not just the transactions built on top of it. Health information, financial history, personal identifiable data, all of it sits in the same platform, often in the same customer record. Launching an e-commerce platform for insurance products taught me that compliance isn't a checklist you complete before launch. It's a set of constraints that shape the architecture from day one.

Data classification comes before anything else

Before writing a line of business logic, I map out what data the system actually handles and classify it: public, internal, sensitive personal data, and regulated data with specific handling requirements. This classification drives real architectural decisions, not just documentation. Regulated fields get encryption at rest with restricted key access, audit logging on every read, and stricter retention policies than general application data.

csharp

public class PolicyHolder
{
    public string Name { get; set; } // internal
    [Encrypted] public string NationalId { get; set; } // regulated, encrypted at rest
    [Encrypted] public string MedicalHistorySummary { get; set; } // regulated, restricted access
}

Skipping this step means retrofitting encryption and access controls onto a data model after launch, which is significantly more expensive and error-prone than designing for it from the start.

Access control needs to answer "why," not just "who"

Role-based access answers who can see a resource. Regulated data often needs to answer why they're accessing it, because a claims adjuster accessing a policyholder's medical history for an active claim is legitimate, and the same adjuster browsing the same record with no active claim assigned is a red flag, even though the role-based check passes identically in both cases.

csharp

public async Task<bool> CanAccessMedicalRecordAsync(Guid userId, Guid recordId)
{
    var activeClaimAssignment = await _claimRepository
        .GetActiveAssignmentAsync(userId, recordId);
    return activeClaimAssignment is not null;
}

This is a meaningfully higher bar than typical role checks, and it requires the domain model to actually represent "why" someone needs access, not just track their role.

Audit logging that's actually useful in an investigation

csharp

_auditLogger.LogAccess(new AuditEntry
{
    UserId = currentUser.Id,
    ResourceType = "MedicalRecord",
    ResourceId = record.Id,
    Action = "Read",
    Justification = "ClaimReview",
    Timestamp = DateTime.UtcNow
});

Generic application logs aren't sufficient for a compliance audit. What regulators and internal auditors actually need is a clear, immutable record of who accessed what, when, and under what justification, queryable independently of the application's own database, so a compromised application can't also compromise its own audit trail. I've treated audit logging as its own regulated system, with its own access controls, separate from general application logging from the start.

Consent isn't a checkbox, it's a lifecycle

Customers consent to specific uses of their data, and that consent can be withdrawn, scoped to specific purposes, or expire. A system that treats consent as a single boolean flag can't actually represent "the customer consented to marketing communications but not to data sharing with third-party partners," which is exactly the kind of granularity regulations like GDPR require.

csharp

public class ConsentRecord
{
    public ConsentPurpose Purpose { get; set; } // marketing, data-sharing, analytics
    public DateTime GrantedAt { get; set; }
    public DateTime? RevokedAt { get; set; }
}

Third-party integrations inherit your compliance obligations

Every external service that touches regulated data, a payment processor, an analytics tool, an AI provider, needs to be evaluated against the same compliance bar as your own system, because a data breach at a vendor you integrated with is still your incident to answer for. I've turned down integrations that looked technically convenient because the vendor couldn't demonstrate adequate data handling practices for the sensitivity of what we'd be sending them.

Building this in from day one versus retrofitting it

The honest lesson from building an insurance platform from the ground up: every one of these considerations is dramatically cheaper to design in from the start than to add after launch. Retrofitting field-level encryption onto a live production database with real customer data, migrating an access control system to support justification-based checks, these are the projects that consume months of engineering time that could have been architecture decisions made once, early, deliberately.