Cloud security and compliance for insurers
An insurer’s cloud security work is judged on evidence. Not on whether access was controlled, but on whether you can show who had access, what they did with it, when it changed, and who approved the change — months or years later, to somebody who was not there. That requirement shapes the architecture more than any individual control does.
Design for the question you will be asked
Most security reviews in this sector reduce to four questions. Building so they can be answered from records rather than from memory is the whole job.
- Who can reach this data?Answerable only if entitlements are granted through groups and roles rather than to individuals. A permission granted directly to a person is invisible in every report that lists roles.
- Who did reach it?Requires access logging on the data itself, not only on the perimeter in front of it.
- What changed, and who approved it?Requires change records tied to the actual change, which is why infrastructure defined as code audits so much better than infrastructure configured by hand: the diff and the approval are the same artefact.
- How do you know the control is still working?Requires continuous checking. A control verified once at implementation is a control whose current state is unknown.
Retention is a storage decision
Logs are the evidence, and evidence has to survive long enough to be asked for. Financial-sector retention obligations commonly run to several years, which turns logging from an operational concern into a capacity one.
Two things follow from the shape of that table. Hot, queryable storage for the whole retention period is rarely justified — investigations almost always concern recent activity, and older logs need to be retrievable rather than instantly searchable. And the tiering has to be designed at the start, because moving several terabytes between storage classes later is itself a project.
Whatever tier they land in, the logs need the same protection as the data they describe. An audit trail an administrator can quietly edit is not an audit trail.
Where insurers specifically get caught
Third-party and intermediary access
Brokers, surveyors, third-party administrators and claims assessors all need access to parts of the estate, and they are outside your identity system. This is usually the widest part of the attack surface and the least reviewed. Federated access with time-bounded entitlements is the mechanism; the discipline is reviewing it on a schedule somebody owns.
Non-production environments holding real data
Test environments restored from a production backup inherit every policyholder record and almost never inherit the controls. Either mask on restore, or accept that your test environment is in scope for everything production is in scope for.
Data inherited from acquisitions
Portfolios acquired from another insurer arrive with data whose lineage, consent basis and retention obligations belong to somebody else’s decisions. Bringing it into a cloud environment without establishing those first is how an estate acquires obligations nobody has recorded.
What to review, and how often
- Entitlements, quarterly, by the person accountable for the data rather than by IT. IT knows who has access; only the business owner knows who should.
- Privileged accounts, monthly.A short list, and the one most worth keeping short.
- Public exposure, continuously.Storage that became reachable from the internet is the single most common cloud incident, and it is detectable automatically.
- Restore, at least annually.Availability is a security property too, and an untested restore is an assumption.
Where this fits
The service is Cloud Security and Compliance, and the sector context is Insurance. It sits on top of Cloud Security, which is the control set itself, and depends on Data Protection for the retention and recoverability side.
