SEC Disclosure · Form 8-K · Regulation S-K · Incident Scoping

This rule does not regulate your code. It puts a clock on a question your build records have to answer.

Fifteen other standards on this site reach your JavaScript through engineering practice. The SEC cybersecurity rules do not reach it at all — they govern what a public company tells investors about a material incident, and how it describes cyber risk management once a year. There is still a reason for a page here, and it is narrower and sharper than the usual compliance argument: the filing deadline attaches to a determination about scope, and a protected bundle changes how quickly you can reach that determination.

Assemble the Evidence Reproducible Builds
The Short Version

Disclosure, not controls

Three contact points, and none of them is an option you switch on.

The clock starts at the determinationFour business days from deciding an incident is material, and that decision is owed without unreasonable delay.
Speed of scoping is the exposureIf you cannot say what was in a build, you cannot reach the determination on time.
A filing is not a marketing pageAnything you claim about protection will be read back to you by people looking for the gap.
What The Rules Actually Require

Two obligations, one continuous and one triggered

The cybersecurity disclosure rules that took effect in December 2023 added two distinct things to a public company's obligations, and they behave completely differently. Confusing them is the most common reason a team builds the wrong readiness work. One arrives on a schedule you control. The other arrives on a schedule an attacker controls.

Item 1.05 of Form 8-K

The triggered one. On determining that a cybersecurity incident is material, a registrant files a current report describing the material aspects of the incident's nature, scope and timing, and its material impact or reasonably likely material impact. Four business days, running from the determination.

Item 106 of Regulation S-K

The annual one. In the 10-K, describe the processes for assessing, identifying and managing material risks from cybersecurity threats, whether risks have materially affected the business, and how the board and management oversee all of it. This is a description of how you work.

What neither one asks

Neither mentions a technique, a tool or a code shape. There is no obfuscation question to answer, no setting to enable, and no credit available for having applied one. A filing that volunteers the topic has added a claim it now has to defend rather than a control it can point to.

The Clock, Read Precisely

Four business days from the determination, and the determination is owed promptly

This is the mechanism that makes the page worth writing, and it is routinely misread as four days from discovery. It is not. The filing deadline runs from the moment you determine an incident is material — and separately, that determination has to be made without unreasonable delay after discovery. Reading only the first half produces a dangerous conclusion: that a slow investigation is a safe investigation.

Slow scoping does not extend the window

Because the determination itself is time-bound, an investigation that cannot establish what was affected does not pause the obligation. It produces a record showing when you knew and when you decided, with the gap in between needing an explanation. A team that spends two weeks working out which build a recovered script came from has created exactly that gap.

Materiality is about impact, not about mechanism

The question is whether a reasonable investor would consider the incident important, which turns on consequence rather than technique. That is good news for engineering: you are rarely asked how the code was written. You are asked what was exposed, for how long, and to whom — and every one of those is a scope question.

Scope questions land on the front end more often than teams expect

A tampered script served from a CDN, a compromised third-party tag, a build shipped with a credential that should never have been bundled, a leaked artefact appearing on a paste site. Each of these begins as a question about what a particular file contained and when it was in circulation.

The answer has to be evidenced, not remembered

Under a deadline, an engineer's recollection of what a build contained is the weakest possible input to a materiality decision, and it is what most organisations are actually running on. A record written at build time and retained is the difference between answering in an hour and arguing for a week.

Where Protection Genuinely Interacts

It changes your investigation speed, not your obligations

This is the honest core of the page, and it cuts in an uncomfortable direction. A protected bundle is harder to read, which is the point — and during an incident, you are one of the people trying to read it. That cost is worth paying, but only if you have already removed it for yourself by keeping the records that map a delivered artefact back to a known build.

The artefact will not look like your source

Identifiers are renamed, structure is rearranged, and string literals may be reconstructed at runtime rather than sitting in the file. Someone handed a recovered copy at 2am cannot diff it against a repository and get a useful answer. That is a designed property, and it applies symmetrically.

Hashes make the question a lookup

A manifest written at build time recording a source hash and an output hash per file turns "what is this file" into a comparison rather than an investigation. A delivered artefact either matches a build you know about or it does not, and both answers are immediately useful.

Determinism removes the argument

With a recorded seed, the same inputs and options regenerate the same output. That converts "we believe this is what we shipped in March" into something you can demonstrate rather than assert — which matters most when the person asking is not in your reporting line.

Per-distribution tags answer "whose copy is this"

Where builds go out per customer or per partner, an embedded tag identifies the distribution an artefact came from. When a leaked file surfaces, the difference between knowing which distribution it belongs to and not knowing is the difference between a scoped incident and an unscoped one.

Retention is the part that gets skipped

Records that exist only for the current release are the wrong shape for this problem. An artefact can surface long after the build that produced it was superseded, and cached copies outlive deployments. Match retention to how long a build can plausibly stay in circulation.

None of this is a security control

Manifests, seeds and tags are evidence and provenance. They do not prevent an incident and should never be described as though they do. Their entire value here is that they compress the time between discovery and a defensible determination.

The Annual Filing

Item 106 rewards a described process and punishes a named product

The annual disclosure is where teams are most tempted to reach for the protection step, because it is a concrete thing they do and the section asks what they do. Resist it. The section asks for processes, and a process has an owner, a trigger, an output and a review. A setting has none of those.

What reads as a process

Client artefacts are built through a pipeline that records what shipped; the record is retained and verifiable; delivered files can be checked against it; findings route into defect handling with named ownership. That is describable, reviewable and testable against reality.

What reads as a product mention

A sentence saying front-end code is obfuscated. It names a step without describing an activity, invites the follow-up question of what risk it manages, and the honest answer to that question is narrower than the sentence implies.

The board-oversight half is not an engineering question

Item 106 also asks who oversees this and how they are informed. That is a governance answer, and engineering's only real contribution is making sure the reporting it feeds upward is accurate about what the pipeline does and does not establish.

Write the claim boundary down internally

One paragraph, kept where the disclosure team can find it: what the protection step does, what it does not establish, and which controls actually enforce authority. It costs an hour and it prevents the sentence you would have to defend later.

A Filing Is Not A Product Page

The claim discipline this site applies everywhere becomes concrete here

Across every other page here, the argument for careful language is professional credibility. In a filing it is something else. A statement to investors gets read back to you by counsel, by regulators and by anyone with an interest in the difference between what you said and what was true — and it gets read after the incident, in the least charitable light available.

Do not let protection imply prevention

A transformation applied to delivered code raises the cost of reading and modifying it. It does not create a trust boundary, it does not authenticate anyone, and it does not stop a determined reader. All three of those are things a filing sentence can accidentally suggest.

Name the controls that carry the weight

Server-side authorisation, key custody, monitoring, third-party script governance. These are the things that actually manage the risk, and a description built from them survives scrutiny in a way one built from a build setting does not.

Client-side code is public by delivery

Anything shipped to a browser reaches its reader. That is a fact about the delivery model rather than a defect in any tool, and a disclosure posture built on it is stable. One built on the hope that a bundle stayed unread is not.

Frequently Asked Questions

Frequently asked questions

Do the SEC cybersecurity rules require us to obfuscate our JavaScript?

No, and they are further from the question than any other rule covered on this site. The other fifteen standards here at least regulate engineering practice in some form. These rules regulate disclosure to investors: what you tell the market about a material incident, how quickly, and what you say every year about how you manage cyber risk. Nothing in them describes source code, build steps or protection techniques, and no filing has ever been improved by asserting that a bundle was obfuscated. What the rules do create is a deadline attached to a question of scope, and that deadline is where a build pipeline either helps you or does not.

When does the four-business-day clock actually start?

Not at discovery. Item 1.05 of Form 8-K requires filing within four business days of determining that an incident is material, and the determination itself must be made without unreasonable delay after discovery. Those are two different obligations and teams routinely collapse them into one. The practical consequence is that slow scoping does not buy you time: a company that takes three weeks to work out what was in a compromised build has not extended the filing window, it has created a record of delay in reaching the determination. This is the specific place where front-end forensics stops being an engineering detail and becomes a disclosure question.

Does a protected bundle make an incident harder to investigate?

It can, and pretending otherwise is how teams get caught out. Renamed identifiers and restructured control flow mean the artefact recovered from a CDN, a customer report or a browser cache does not read like your source. If the only copy of the mapping between that artefact and the build it came from lives on a developer laptop or a build agent that was recycled, you have made a scope question expensive at the worst possible moment. The fix is not to protect less. It is to keep the records that turn the artefact back into a known build, and to keep them for as long as the artefact might plausibly resurface.

What should Item 106 say about our build pipeline?

Describe processes, not products. Item 106 asks how you assess, identify and manage material risks from cybersecurity threats, and a process is something with inputs, owners and outputs. A pipeline that produces a manifest of what shipped, retains it, and can verify a delivered artefact against it is describable in those terms. The word obfuscation is not, and a filing that leans on it is describing a setting rather than a process. The safest framing is the one that is also true: the protection step is applied to delivered client code and is not relied on as a control, while the integrity and provenance records the same pipeline produces are what support the process description.

Is there a risk in overstating protection in a public filing?

Yes, and it is a different category of risk from a marketing overstatement. Copy on a product page that oversells a technique is a credibility problem. The same sentence in a 10-K is a statement to investors that has to survive being read back to you after an incident, by people whose job is to find the gap between what you said and what was true. This is the strongest practical argument for the claim discipline this site applies everywhere else: describe the attacker cost you actually raise, name the controls that actually enforce authority, and never let a filing imply that a client-side transformation prevented something.

Which build records are worth retaining for this specifically?

Four, and they are cheap next to the cost of not having them. A manifest written at build time recording a source hash and an output hash per file, so a recovered artefact can be matched to a build. A signed release attestation over that manifest, so the record itself is verifiable later. A reproducible-build seed, so the same inputs and options regenerate the same output rather than leaving you to argue from memory. And a watermark tag where builds are distributed per customer, so an artefact found in the wild identifies the distribution it came from. Retention is the part teams get wrong: match it to how long a build can plausibly stay in circulation, not to a sprint.

Related Guides

Where to read next

Reproducible builds and the seed

How a recorded seed makes the same inputs and options regenerate the same output, and why that turns an assertion into a demonstration.

SOX and GLBA

The adjacent US financial obligations, where the questions are about controls over reporting and customer information rather than disclosure timing.

ISO 27001 and SOC 2

Why neither standard names obfuscation, and why writing a protection step into your Statement of Applicability creates a population an auditor will sample.

Next Step

Shorten the scoping exercise before you need it

Nothing on this page is a filing decision, and none of it belongs to engineering alone. What does belong to engineering is the part that determines how fast the determination can be made. Write a manifest on every release and retain it past the life of the deployment. Record the seed. Sign the manifest so the record is verifiable later. Where builds go out per customer, embed a tag so an artefact in the wild identifies its distribution. Then write down, in one internal paragraph, what the protection step does and does not establish — so that when a sentence about it is proposed for a filing, someone can check it against something true.

Build the Evidence Packet Protection Overview