South Carolina Insurance Data Security Act: Data Security Requirements and How to Prove “Reasonable Security”
South Carolina Insurance Data Security Act: Data Security Requirements and How to Prove “Reasonable Security”
If you’re an insurer or insurance licensee doing business in South Carolina, you now have two layers of data security law to worry about:
- The general South Carolina data breach notification law (S.C. Code § 39‑1‑90), and
- The South Carolina Insurance Data Security Act (Title 38, Chapter 99), which imposes sector‑specific cybersecurity and incident reporting requirements on insurance licensees.
Directors, CISOs, and compliance leaders keep asking the same core questions:
- Exactly who does the Insurance Data Security Act apply to?
- What does “reasonable security” actually mean under this law?
- How does it interact with the general breach notification statute?
- And how can we prove compliance when an exam or incident happens?
This post walks through the law in plain language and, more importantly, shows how data‑centric security and DSPM make it far easier to demonstrate that you’re doing the right things.
What is the South Carolina Insurance Data Security Act?
The South Carolina Insurance Data Security Act (SCIDSA) is codified at Title 38, Chapter 99 of the South Carolina Code of Laws. It was enacted in 2018 and is modeled closely on the NAIC Insurance Data Security Model Law.
In short, it:
- Requires insurance licensees to develop, implement, and maintain a comprehensive written information security program based on a risk assessment.
- Imposes specific obligations around incident response, investigation, and reporting of cybersecurity events to the SC Department of Insurance.
- Mandates oversight of third‑party service providers that access nonpublic information.
- Requires annual certification of compliance to the Director of Insurance (for domestic insurers).
Think of it as the insurance‑specific overlay on top of South Carolina’s general breach law and any federal obligations you may have (GLBA, HIPAA for certain products, etc.).
Who does the Act apply to?
The Act applies to “licensees” that are licensed, authorized, or registered (or required to be) under South Carolina’s insurance laws, with certain exceptions.
That includes, for example:
- Insurers (life, P&C, health, specialty carriers)
- HMOs and many health plans regulated as insurers
- Producers, agencies, and certain intermediaries
- Other entities holding a license from the SC Department of Insurance
There are some exemptions. For instance, licensees with fewer than a specified number of employees or licensees already compliant with equivalent requirements in another state, but they are narrow, and you should confirm applicability with counsel.
If you’re writing policies in South Carolina or handling SC policyholder/insured data, you should assume SCIDSA applies until you’ve proven otherwise.
What does the law require? (High‑level overview)
At a high level, the Insurance Data Security Act requires licensees to do five big things:
- Build and maintain a written information security program that is risk‑based and appropriate to your size, complexity, and the sensitivity of your data.
- Conduct regular risk assessments to identify reasonably foreseeable threats to nonpublic information and your information systems.
- Implement controls across administrative, technical, and physical domains—covering access control, encryption, monitoring, incident response, and more.
- Oversee third‑party service providers that handle nonpublic information on your behalf, ensuring they maintain appropriate security.
- Investigate and report cybersecurity events to the SC Department of Insurance within defined timelines, and maintain documentation and records for exam and enforcement purposes.
What follows is a closer look at the pieces that matter most from a data‑security and breach‑readiness perspective.
Nonpublic information: what are you actually protecting?
The Act uses the term “nonpublic information” rather than just PII. That typically includes:
- Business‑related information that, if tampered with or disclosed, would materially impact your operations or security.
- Consumer information that can identify a person when combined with data elements like SSNs, financial account numbers, or driver’s license numbers—similar to but often broader than the general breach law’s definition.
- Certain health or medical information associated with insurance products.
For insurers, this often spans:
- Policyholder and applicant records
- Claims data and adjuster notes
- Payment and bank details
- Underwriting models and internal risk scoring data
- Credentials and MFA secrets granting access to core systems
This “nonpublic information” is what your information security program, and your incident response obligations, are ultimately organized around.
“Reasonable security” under SCIDSA: more than a buzzword
Many laws talk about “reasonable” or “appropriate” safeguards. The Insurance Data Security Act goes further by spelling out what a risk‑based program must include, such as:
- Designating one or more responsible individuals (or an outside vendor) to oversee the information security program.
- Conducting and documenting periodic risk assessments of threats to nonpublic information and information systems.
- Implementing controls for:
- Access controls and authentication
- Physical and environmental security
- Encryption or equivalent protections for data in transit and at rest
- Secure development practices for internally built applications
- Monitoring, logging, and testing for unauthorized access or changes
- Incident response planning and disaster recovery
For licensees with a board of directors, executive management must regularly report to the board (or a committee) on the overall status of the information security program, material risks, and recommended changes.
This is the statutory backbone behind a regulator or plaintiff saying, “Did you have reasonable security in place?”
Cybersecurity events and reporting: what triggers notice?
The Insurance Data Security Act introduces the defined concept of a “cybersecurity event”—broadly, an event resulting in unauthorized access to or disruption of an information system or nonpublic information, with some carve‑outs (such as access that is determined not to have been used or released and has been returned or destroyed).
When a licensee learns that a cybersecurity event has occurred or may have occurred, it must conduct a prompt investigation to determine:
- Whether a cybersecurity event actually occurred
- The nature and scope of the event
- What nonpublic information may have been involved
- What measures are needed to restore system security and prevent recurrence
Department of Insurance notification
A licensee must notify the Director of the Department of Insurance of a cybersecurity event no later than 72 hours after determining that such an event has occurred, when either:
- South Carolina is the licensee’s state of domicile (for insurers) or home state (for producers), or
- The event involves the nonpublic information of at least 250 South Carolina consumers and either:
- The event must be reported to another governmental body or regulator, or
- The event is reasonably likely to materially harm a South Carolina consumer or a material part of the licensee’s normal operations.
The notice to the Director must include, as much as possible at the time:
- Date and nature of the event
- How information was exposed, lost, or accessed
- Types of nonpublic information involved
- Number of SC consumers affected
- Law enforcement involvement
- Steps taken to investigate, remediate, and notify consumers
The Constangy Cyber and other practitioner summaries emphasize that these requirements layer on top of, not in place of, your obligations to consumers under § 39‑1‑90 and any federal laws.
Interaction with the general breach notification statute
SCIDSA is explicit that licensees must still comply with S.C. Code § 39‑1‑90 for consumer notice, where applicable. In other words:
- SCIDSA: Notice to the Director of Insurance (regulator) within ~72 hours in certain thresholds and conditions.
- § 39‑1‑90: Notice to South Carolina residents, the Department of Consumer Affairs, and credit bureaus based on the scope of the breach and harm threshold.
For insurance CISOs and compliance officers, the practical takeaway is that you must design an incident response program that simultaneously satisfies both statutes, plus any other state or federal obligations in the jurisdictions where you operate.
Why this is hard in 2026: the data sprawl reality
On paper, the Insurance Data Security Act reads like a classic security program checklist. In practice, the hardest parts are:
- Knowing where nonpublic information actually resides across policy admin platforms, claims systems, data warehouses, email, collaboration tools, and third‑party SaaS.
- Understanding real‑world access—not just IAM roles on paper, but which users, service accounts, vendors, and AI tools can actually touch sensitive data.
- Quantifying impact quickly during an incident so you can meet the 72‑hour Department of Insurance clock and the “most expedient time possible” obligation for consumer notice.
Most insurers have grown through acquisition, product launches, and third‑party integrations. That means policyholder and claimant data often exists in:
- Multiple core systems and data lakes
- Historical archives and backups nobody has looked at for years
- Ad‑hoc exports shared with vendors or internal analytics teams
- Email and collaboration workspaces, often with full Excel dumps attached
Without continuous, accurate visibility into that sprawl, your ability to prove “reasonable security” and respond within statutory timelines depends more on luck than design.
How data‑centric security and DSPM help prove compliance
This is where Data Security Posture Management (DSPM) and data‑centric security come into play.
A modern DSPM platform like Sentra is designed to answer, continuously and at scale, the core questions baked into the Insurance Data Security Act:
- What nonpublic information do we actually hold?
- Where does it reside across cloud, SaaS, and on‑prem?
- How is it protected (encryption, masking, labeling, access controls)?
- Who or what can access it—humans, APIs, AI agents, third‑party vendors?
Sentra does this by:
- Discovering and classifying sensitive data across your clouds, SaaS, and on‑prem data stores, including policy/claims systems, warehouses, and collaboration tools.
- Building a live, context‑rich inventory of regulated data (PII, PCI, health, credentials, etc.) and mapping it to your environments and business units.
- Continuously analyzing exposure and effective access, so you see where nonpublic information is overshared, unencrypted, or accessible from risky identities.
- Integrating with your incident response workflows, so that when a security event occurs, you can quickly scope which data sets and how many consumers are truly in play.
A real‑world parallel: SoFi’s DSPM story
While SoFi is a financial services leader rather than an insurer, their story closely mirrors the challenges SC insurers face.
In our webinar and case study with SoFi, their security leaders describe how they used Sentra to:
- Create a centralized data catalog of sensitive customer data across a complex cloud environment.
- Improve compliance mapping by aligning data classes with regulatory frameworks and internal policies.
- Tighten data access governance, reducing false positives and focusing on the exposures that matter most.
Their experience moving from scattered, manual efforts to automated, high‑confidence visibility and classification is exactly what SC insurers need to align day‑to‑day operations with SCIDSA’s “reasonable security” and incident reporting expectations.
Making the Insurance Data Security Act manageable
If you’re an insurance licensee in South Carolina, the path forward looks something like this:
- Confirm applicability and scope with legal counsel, but assume SCIDSA and § 39‑1‑90 both matter if you hold South Carolina policyholder or claimant data.
- Inventory your nonpublic information using automated discovery and classification—it’s no longer realistic to do this with spreadsheets.
- Align your risk assessment and controls with what the Act explicitly requires: access control, encryption, monitoring, incident response, and third‑party oversight.
- Instrument your incident response so that every suspected cybersecurity event immediately pulls in DSPM context: data types, consumers affected, exposure level, and cross‑jurisdiction triggers.
- Document everything: risk assessments, board reports, incident investigations, and rationales for notification or non‑notification decisions. This is what “reasonable security” looks like under exam.
With that in place, the next early‑morning call from the SOC won’t feel like a blind scramble against a 72‑hour clock. You’ll be operating from a place of data‑driven confidence, not guesswork.
Call to action
If you’re responsible for data security or compliance under the South Carolina Insurance Data Security Act, now is the time to get ahead of the next exam—or the next incident.
See how Sentra helps insurers continuously map nonpublic information, reduce exposure, and accelerate investigations so you can meet SCIDSA and § 39‑1‑90 obligations with confidence.

