ISO/IEC 27001 · SOC 2 · Annex A · Trust Services Criteria

Neither standard asks whether your JavaScript is obfuscated. Both ask whether you can evidence what you claim.

These are the two attestations most often demanded of a software vendor, and they are the two that say least about technique. What they examine is whether a defined process ran consistently over a period, which turns a build-pipeline sentence into something an auditor will sample.

Security Evidence Packet Reproducible Builds
The Short Version

Process, evidence, consistency

Three things to settle before your next readiness meeting.

No control names obfuscationAcross ninety-three Annex A controls and the Trust Services Criteria, the technique appears nowhere.
Naming it makes it testableA control in your Statement of Applicability has a population, and in a Type II that population is every release.
Records beat assertionsManifest, signature, seed and a gate that fails the build are what survive sampling months later.
What The Two Standards Are

One certifies a management system, the other reports on controls over a period

These two get named in the same breath by buyers and they are structurally different things. Knowing which one you are answering changes what evidence is worth building, and it changes what a sentence about your build pipeline is committing you to.

ISO/IEC 27001

A certifiable management-system standard. You define a scope, run a risk assessment, select controls, and publish a Statement of Applicability against the ninety-three Annex A controls of the 2022 revision, recording for each whether it applies and why. An accredited body audits the system, not any individual technology choice.

SOC 2

Not a certification at all. It is an attestation report written by a CPA firm against the AICPA Trust Services Criteria, with Security as the mandatory common criteria and Availability, Confidentiality, Processing Integrity and Privacy added by choice. The output is a report a customer reads, not a certificate you display.

What neither one says

Neither control set names obfuscation, minification, or any client-side code transformation. There is no control that a protected bundle satisfies and no box it ticks. Anyone telling you a protected bundle is required by either standard is describing a sales position rather than the text.

Where Client-Side Code Genuinely Appears

A short cluster of controls, all of them about process

Client-side JavaScript is not absent from these frameworks; it is covered by controls written at a level of abstraction above any technique. Read them and the same shape appears every time: define the process, apply it consistently, be able to show that you did.

Secure development, A.8.25 and A.8.26

A defined life cycle for how software is built, and security requirements identified for applications. A build step that transforms delivered code sits inside that life cycle. What is assessed is whether the life cycle is documented and followed, not which transform you selected.

Secure coding and source access, A.8.28 and A.8.4

Coding standards and rules for who can reach source. Worth noting because obfuscation is sometimes offered as an answer here and it is the wrong layer: A.8.4 is about access to your repository, which a transform applied at build time does not address in either direction.

Environment separation, A.8.31

Development, test and production kept apart. Relevant in a specific way for protected builds: if the protection step only runs in production, then what you tested is not what you shipped, and your test evidence covers a different artefact. That gap is a finding waiting to be written.

Change management, A.8.32 and CC8.1

The control that does most of the work in both frameworks, and the one your build pipeline actually answers. Changes are authorised, tested, recorded and traceable to what was deployed. A per-release record of what was produced is exactly the artefact this asks for.

The Honest Core

Writing it down is what makes it testable

This is the part worth carrying into your next readiness meeting, because it inverts the instinct. The instinct is that naming a protective measure strengthens your position. In an audit it does the opposite: it creates an obligation with a population and a sample size.

A named control gets a population

Put obfuscation in your Statement of Applicability or your system description and it stops being a build preference. It becomes a control, and the population is every release in scope. In a Type II engagement covering several months, that is every deployment you made.

One skipped release is an exception

A hotfix pushed by hand, a rollback that redeployed an older artefact, a pipeline branch that omitted the step. Any of these becomes a testing exception, and exceptions are written into a report that prospects and customers read. The technique did not fail; the consistency claim did.

Describe the process you can evidence

The safer framing is also the more accurate one. Describe a release-integrity process with recorded outputs and a gate that stops a release which did not go through it. The protection step is one stage inside that process, evidenced by the same records, without being the claim under test.

Evidence That Survives Sampling

Four records that answer change-management questions per release

Auditors sample. The question is never whether a pipeline exists today, it is whether you can produce, for a release chosen from eight months ago, the record of what went out. These four artefacts are what turn that from an archaeology exercise into a lookup.

A manifest, written at build time

A source hash and an output hash for every file in the release. This is what lets you take an artefact recovered from a CDN or a customer and match it to a build you authorised, which is precisely the traceability change management asks for.

A signed attestation over the manifest

A signature makes the record verifiable later rather than merely present. It matters because the evidence is being examined months after the fact by someone whose job is to ask how they would know the file was not edited afterwards.

A recorded build seed

With the seed stored alongside the release, the same inputs and options regenerate the same output. That converts a claim into a demonstration you can run in front of the auditor. The documentation is clear that a fixed seed is not itself a security control; its value here is evidential.

A gate that fails the build

The control that makes the other three trustworthy. If a pipeline path can produce a shippable artefact without the step running, then your evidence describes intent rather than practice. A gate that fails a release which skipped the step is what closes the sampling risk.

Third-Party Risk

Your auditor will ask about the tool as well as the technique

Supplier controls are where a build-time tool becomes a scope question. Annex A covers this in A.5.19 to A.5.22, with cloud services in A.5.23; SOC 2 covers the same ground in CC9.2. The answer depends on which protection path you run, and the difference is worth deciding deliberately rather than discovering during fieldwork.

The hosted path is a vendor in scope

If selected JavaScript is sent to a hosted service for protection, that service handles your code and belongs in your supplier register, with the same diligence you apply to any processor touching intellectual property.

A local path narrows the question

Where protection runs on your own machine, the source does not leave it and the relationship reduces to licensing and entitlement. That is a materially shorter answer to give a reviewer. Virtualised bytecode remains a hosted capability by design, so check which features your configuration depends on.

What we do not claim

JavaScript Obfuscator does not hold an independent SOC 2 or ISO 27001 attestation, and our security and trust page says so plainly rather than implying otherwise. Treat any vendor claim in this space, including ours, as something to request in writing.

Frequently Asked Questions

What teams ask before fieldwork

Does ISO 27001 or SOC 2 require us to obfuscate our JavaScript?

Neither one mentions it. ISO/IEC 27001 is a management-system standard whose Annex A lists ninety-three controls, and SOC 2 is an attestation against the AICPA Trust Services Criteria. Read both control sets end to end and you will not find obfuscation, minification or any named client-side transformation. What you will find are requirements about secure development, change management, separation of environments and access to source code, all of which are about process and evidence rather than technique. A protected bundle does not satisfy a control on its own, and no auditor will accept it as one.

So is there any point mentioning it to an auditor?

Only if you are prepared for it to be tested. This is the single most useful thing to understand about both standards: naming something as a control makes it auditable. If obfuscation appears in your Statement of Applicability or your SOC 2 system description, it becomes a control with a population, and in a Type II engagement that population is every release in the observation period. A release that skipped the step is an exception, and exceptions appear in a report your customers read. Most teams are better served describing the release-integrity process they can evidence and leaving the protection step as an implementation detail inside it.

What is the difference between a Type I and a Type II report here?

Type I opines on whether controls are suitably designed at a single point in time. Type II opines on whether they operated effectively across a period, commonly somewhere between three and twelve months. That distinction is what turns a build-pipeline claim from a screenshot into a sampling exercise. For a Type I you can show that the pipeline is configured to protect the bundle. For a Type II the auditor selects releases from across the period and asks you to demonstrate, per release, that the step ran and that the artefact shipped is the artefact the pipeline produced. If your evidence only exists for the current build, that is a problem you want to find before fieldwork.

Which Annex A controls are the ones that actually touch client-side code?

In the 2022 revision the relevant cluster is technological: A.8.25 on the secure development life cycle, A.8.26 on application security requirements, A.8.28 on secure coding, A.8.31 on separating development, test and production environments, and A.8.32 on change management, with A.8.4 covering access to source code. The SOC 2 analogue is mostly CC8.1 for change management, supported by the CC6 access criteria and CC7 for operations and monitoring. None of them prescribe a technique. All of them ask whether a defined process is followed consistently and whether you can show it.

Our auditor asks about our vendors. Where does JavaScript Obfuscator sit?

It depends entirely on which protection path you use, and it is worth settling before the questionnaire arrives. Annex A covers supplier relationships in A.5.19 through A.5.22 and cloud services in A.5.23; SOC 2 handles the same ground in CC9.2. If you use the hosted protection path, selected JavaScript is sent to a third-party service and that service is a vendor inside your scope. If you use a local path, the source stays on your machine and the vendor relationship narrows to licensing and entitlement rather than code handling, which is a materially easier answer to give. Note also that JavaScript Obfuscator does not itself hold a SOC 2 or ISO 27001 attestation, which our security and trust page states directly rather than implying otherwise.

What is the most useful thing we can build for these audits?

A per-release evidence trail, because it answers change-management questions for both standards at once and it is cheap next to the cost of reconstructing it later. Four artefacts do most of the work: a manifest recording a source hash and an output hash for every file in the release, a signed attestation over that manifest so the record is verifiable after the fact, a recorded build seed so the same inputs and options regenerate the same output rather than leaving you to argue from memory, and a pipeline gate that fails the build when the protection step did not run. Retain them per release for at least the length of your observation period.

Related Guides

Where to read next

Our security and trust position

What is published about source handling and release validation, including the plain statement that no third-party attestation is held.

SOX and GLBA

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

PCI DSS 6.4.3 and 11.6.1

The one regime on this site that does prescribe named client-side requirements, and how it differs from a management-system standard.

FIPS 140-3 and Common Criteria

Why a validated cryptographic module is a different claim from an approved algorithm, and why a transform is neither.

Next Step

Build the record before the observation period starts

Almost everything expensive about these audits comes from evidence that was never captured while it was cheap to capture. Decide now whether the protection step is going to be a named control or an unnamed stage inside a release process you can evidence, and write that decision down. Then make the pipeline produce a manifest on every release, sign it, record the seed, and add the gate that stops a release which bypassed the step. If your observation period has not started yet, this is the least expensive week you will ever have to do it in.

Build the Evidence Packet Reproducible Builds