South Carolina Data Breach Notification Requirements: What CISOs Need to Know About SC Code § 39‑1‑90
South Carolina Data Breach Notification Requirements: What CISOs Need to Know About SC Code § 39‑1‑90
Imagine you’re the CISO of a fast‑growing company in Charleston. It’s 6:30 a.m., and your phone lights up with a message from the SOC: suspicious activity in a cloud database that holds customer information.
The good news: logs show you caught it quickly. The bad news: you’re doing business in South Carolina, and that means SC Code § 39‑1‑90, the state’s data breach notification law, just became very real.
Within hours, your executive team will want answers:
- Is this a “breach of the security of the system” under South Carolina law?
- Do we have to notify South Carolina residents?
- What about the Consumer Protection Division and credit bureaus?
- How fast do we need to move—and what happens if we get it wrong?
To answer those questions confidently, you need more than a legal summary. You need a clear view of your data: where South Carolina residents’ information actually lives, how it’s protected, and how many people could be affected in a worst‑case scenario.
This article walks through the law and the operational reality behind it.
Who South Carolina’s breach law applies to
South Carolina’s general breach notification statute, S.C. Code § 39‑1‑90, applies broadly to any “person conducting business in this State” that owns or licenses computerized data (or other data) including personal identifying information of South Carolina residents.
It also covers organizations that maintain such data on behalf of someone else, even if they don’t own it.
In practice, that means:
- South Carolina–headquartered companies
- Out‑of‑state companies doing business in SC and holding SC residents’ data
- Many types of commercial entities, and even some governmental subdivisions
There are limited carve‑outs for example, financial institutions already in compliance with Gramm‑Leach‑Bliley Act (GLBA) privacy and security provisions can be deemed compliant under certain circumstances. But most organizations handling consumer data should assume they’re squarely in scope.
What “personal identifying information” means in South Carolina
Under § 39‑1‑90(D)(3), “personal identifying information” is defined as a South Carolina resident’s first name or first initial and last name in combination with one or more of the following, when not encrypted or redacted:
- Social Security number
- Driver’s license number or state identification card number
- Financial account number, credit card number, or debit card number plus any required security code, access code, or password that would permit access to a financial account
- Other numbers or information that may be used to access a person’s financial accounts, or numbers or information issued by a governmental or regulatory entity that uniquely identify an individual
Information that is lawfully available from public records, or already public, is excluded.
The key is that South Carolina is focused on financial and identity‑enabling data elements, not every piece of PII you might hold. But in a modern environment with backups, exports, analytics, and AI pipelines, those elements often end up in more places than you expect.
What counts as a “breach of the security of the system”
South Carolina law defines a “breach of the security of the system” as unauthorized access to and acquisition of computerized data (not rendered unusable through encryption, redaction, or other methods) that compromises the security, confidentiality, or integrity of personal identifying information when:
- Illegal use of the information has occurred, or
- Illegal use is reasonably likely to occur, or
- Use of the information creates a material risk of harm to a resident
There are a few important qualifiers:
- Good‑faith access by employees or agents for legitimate business purposes is not considered a breach, provided the data is not used improperly or further disclosed.
- If data is properly encrypted, redacted, or otherwise rendered unusable, the statute does not apply.
External analyses, such as Davis Wright Tremaine’s summary, emphasize that the risk‑of‑harm threshold is real: notification is generally required only if illegal use has occurred or is likely, or if there’s a material risk of harm.
That sounds flexible. In practice, it means you need facts—not guesses—about the data involved before you decide whether to notify.
Notification obligations and timelines
Once you determine that a breach of the security of the system has occurred, SC Code § 39‑1‑90 imposes several notification duties.
Notification to South Carolina residents
If you own or license the data, you must notify affected South Carolina residents “in the most expedient time possible and without unreasonable delay” after discovery, taking into account law enforcement needs and efforts to determine the scope of the breach and restore system integrity.
The statute doesn’t prescribe a specific number of days, but third‑party guides like the Davis Wright Tremaine and Mintz matrices reinforce that regulators will look closely at whether your investigation and response were reasonable in context.
Notice can be delivered by:
- Written letter
- Telephone
- Electronic notice, where appropriate under E‑SIGN and state law
If the cost or scale is prohibitive (e.g., more than 500,000 people affected or notification would cost over $250,000), substitute notice is permitted, typically combining email (if available), website posting, and major statewide media.
Unlike some states, South Carolina does not prescribe detailed content requirements for consumer notices, but best practice—reflected in many AG and regulator expectations—is to describe the incident, the type of information involved, and what you’re doing about it.
Notification to the Department of Consumer Affairs
If you notify more than 1,000 South Carolina residents about a breach, you must also notify, without unreasonable delay:
- The Consumer Protection Division of the South Carolina Department of Consumer Affairs, and
- All nationwide consumer reporting agencies (credit bureaus) about the timing, distribution, and content of your consumer notice
Note that this is not the Attorney General; South Carolina’s primary regulator for breach notices is the Department of Consumer Affairs.
Notification by third‑party data custodians
If you maintain personal identifying information on behalf of another entity, but don’t own it, you must notify the owner or licensee of any breach immediately following discovery.
For service providers, this means notification clauses and SLAs in customer contracts need to line up with statutory expectations.
Enforcement, penalties, and private lawsuits
South Carolina’s statute has real teeth.
A resident injured by a violation may bring a civil action to:
- Recover damages for willful and knowing violations, or
- Recover actual damages for negligent violations
- Seek an injunction to enforce compliance
- Recover attorneys’ fees and court costs if successful
Separately, a person who knowingly and willfully violates the statute is subject to an administrative fine of $1,000 per South Carolina resident whose information was accessible because of the breach, as determined by the Department of Consumer Affairs.
Legal summaries from firms like Davis Wright Tremaine, Constangy, and Mintz all underscore that South Carolina offers both regulatory enforcement and a private right of action, making it riskier to treat breach obligations as a check‑the‑box exercise.
Where CISOs get stuck: the “material risk of harm” problem
On paper, South Carolina’s harm threshold sounds friendly to businesses: notification isn’t required if you reasonably believe illegal use has not occurred and isn’t likely, or if the incident doesn’t create a material risk of harm.
In real incidents, that’s exactly where CISOs and legal teams get stuck.
To make that judgment call—especially one you’re comfortable defending to regulators, plaintiffs’ lawyers, and your own board—you need to answer a few hard questions fast:
- What exact data did the attacker access, copy, or have the opportunity to exfiltrate?
- Was it really rendered unusable by encryption or tokenization, or were keys and secrets in the same blast radius?
- How many South Carolina residents had personal identifying information in those datasets?
- Was access limited to a tightly scoped subset, or were you dealing with a broad analytics cluster or data lake that’s been accreting identity and financial data for years?
In many organizations, getting those answers requires days or weeks of manual work: exporting schemas, sampling records, cross‑referencing customer locations, and hoping you didn’t miss the one legacy bucket with a full set of unencrypted account numbers.
That delay is exactly what “most expedient time possible and without unreasonable delay” is designed to avoid.
Why DSPM is becoming a necessity for South Carolina breach readiness
This is where Data Security Posture Management (DSPM) shifts from buzzword to practical foundation.
DSPM focuses on continuously discovering, classifying, and assessing the risk posture of sensitive data across cloud, SaaS, and on‑prem environments—so you can answer, on demand, the questions South Carolina’s law implicitly asks: what data, whose data, how exposed, and how bad is the harm?
Continuous visibility into SC‑regulated data
A modern DSPM platform like Sentra connects agentlessly to cloud providers, data warehouses, SaaS apps, and on‑prem data stores, building a live map of:
- Where sensitive data lives
- Which datasets contain personal identifying information that fits South Carolina’s definition
- How that data is protected (encryption, access controls, masking)
- Who can actually access it, including service accounts and AI assistants
That means when an incident hits an S3 bucket, a Snowflake database, or a collaboration platform, you’re not starting from zero—you already know which assets in that blast radius contain South Carolina residents’ identity and financial data.
From law-on-paper to incident decisions
The value becomes clear in the heat of an investigation. Instead of arguing in the abstract about “material risk of harm,” your security and legal teams can look at concrete facts:
- The compromised system contained N records with name + account numbers for South Carolina residents, unencrypted.
- The attacker had read access for T minutes, during which exfiltration events were/weren’t observed.
- Keys for encrypted datasets were in a separate KMS environment and not accessed.
Those details don’t just drive whether notice is required; they also shape the narrative with regulators and consumers when you do notify.
A real‑world example: SoFi’s DSPM journey with Sentra
While SoFi isn’t a South Carolina case, their story illustrates what this looks like in practice.
The SoFi security team operates in a heavily regulated financial environment, with a complex cloud‑native data landscape. In a recent webinar and blog, SoFi’s Director of Product Security and Senior Staff Application Security Engineer described how they used Sentra’s DSPM to:
- Build a centralized data catalog with accurate, automated discovery and classification of sensitive data
- Map data assets to regulatory requirements and internal security policies
- Strengthen data access governance, reducing over‑permissioning and improving their ability to answer “who can see what, and why?”
Their challenge—data sprawl, lack of visibility, compliance pressure—is the same pattern CISOs in South Carolina see every day. The difference is that, with DSPM, SoFi moved from reactive fire drills to a proactive, continuously updated view of risk.
That’s exactly the posture you want when you’re making high‑stakes decisions under a state law that hinges on “reasonable belief” and “material risk of harm.”
Bringing it all together for South Carolina
If you operate in South Carolina, breach readiness isn’t just about having a playbook and a PR statement. It’s about being able to prove, under pressure, that you:
- Know where South Carolina residents’ personal identifying information actually lives
- Can quickly determine whether a given incident meets SC Code § 39‑1‑90’s definition of a breach
- Can back up your harm assessments with data, not intuition
- Can notify residents, regulators, and credit bureaus without unreasonable delay—and without having to issue embarrassing corrections later
DSPM gives you the substrate for those decisions. From there, you can integrate it into:
- Your incident response plans, so every major incident automatically pulls in data classification and exposure context
- Your governance processes, so you reduce breach blast radius over time by cleaning up shadow data and tightening access
- Your board and regulator communications, with concrete, continuously updated metrics instead of static spreadsheets
South Carolina’s law is not unique in the US—but it’s a clear example of where data‑centric security and legal obligations now meet.
If you’d like to see what South Carolina breach readiness looks like with real‑time data intelligence, we can show you.
See how Sentra maps sensitive data, exposure, and risk so you can make faster, defensible decisions under SC Code § 39‑1‑90. Request a Sentra demo

