Software Supply Chain Security for HR Tech and Payroll: A 90-Day Plan

Software supply chain security for an HR tech or payroll company comes down to three jobs: know every open source and third-party component inside the software you build (the payroll engine, the employee app, the integration layer), know which vendor runs every system you buy or connect to (file transfer, identity, benefits carriers, time clocks), and put both on a patch clock that someone owns and can prove to a SOC 1 or SOC 2 auditor, a Nacha audit, a plan fiduciary or a customer's security team. Employers who buy HR and payroll software carry the mirror image of the same job: they need the vendor's evidence, not just its logo. A focused team can stand up the inventory, the gates and the vendor evidence in about 90 days.

This guide covers the software the industry runs, the US rules that apply, public incidents from the last three years, the people who own each part, and a 30, 60 and 90 day plan that works with whatever tools you have. Safeguard appears only near the end. Nothing here is legal, regulatory or audit advice; your counsel, your service auditor and your bank partners decide what applies to you.

Key takeaways

• HR and payroll systems hold the densest personal data most companies keep: Social Security numbers, bank account and routing numbers, dates of birth, benefit elections, I-9 documents and, for time clocks, biometrics. A single vulnerable component in the stack can expose all of it.
• The supply chain runs in two directions. A payroll provider consumes thousands of open source components and dozens of vendors, and is itself a critical vendor to every employer it pays.
• No single US law says "software supply chain" for HR tech. The obligations arrive through SOC 1 and SOC 2 reports, the Nacha Operating Rules for anyone moving payroll over ACH, the Department of Labor's cybersecurity guidance for benefit plan service providers, HIPAA for benefits data, the CCPA (whose employee data exemption expired at the end of 2022) and, for public companies, the SEC's incident disclosure rules.
• Nacha's fraud monitoring rules took effect on 20 March 2026 for the largest originators and senders and on 19 June 2026 for the rest. Account number protection at rest has applied to senders above 2 million entries a year since 30 June 2022.
• Incidents in this industry are mostly third-party incidents: a file transfer tool, a compromised open source package, a vendor's CRM. Plan for them as vendor events with a clock attached.
• The 90 day plan: inventory in month one, gates and vendor tiering in month two, evidence and a rehearsed incident in month three.
• In Safeguard, every capability this post uses is generally available (GA): SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis and prioritization, policies and gates, autonomous remediation (ships switched off), license compliance, SAST and DAST, Third-Party Risk Manager (TPRM), the Compliance and GRC suite, Trust Center, Portal audit trails, the CLI and local runner, Zero AI mode and on-prem or air-gapped deployment.

What software HR tech and payroll runs

HR technology is a stack of systems that each touch the same employee record. The names vary by vendor; the system types do not.

Why the supply chain is so wide here

First, payroll is a concentration point. One provider pays employees at many employers, so one vulnerable component in its stack becomes an incident for every customer at once. That is why employers ask for SOC reports, questionnaires and, increasingly, SBOMs.

Second, integrations are the product. A mid-sized employer may connect its HRIS to a payroll provider, a benefits platform, a 401(k) recordkeeper, several insurance carriers, an applicant tracking system, a background check service and the general ledger. Each link is code someone maintains, a credential someone stores and a data flow someone explains to an auditor.

Third, the calendar is unforgiving. Payroll runs on fixed dates, year-end processing produces every W-2 in a few weeks, and open enrollment compresses benefits changes into a short window each autumn. Teams freeze code during those windows, which is exactly when a critical CVE tends to land. A supply chain program here has to work inside a freeze, not only between them.

The regulations and frameworks that apply

This section lists the rules a US HR tech or payroll company usually meets, with status checked on 25 October 2026. Which ones apply depends on what you do, whose data you hold and how much volume you move. Treat it as a map for your counsel and service auditor.

SOC 1 and SOC 2 reports

For a payroll provider, the SOC report is the main way customers and their auditors judge its controls. The AICPA defines two reports that matter here.

The AICPA describes SOC 1 as an examination of controls at a service organization that are likely to be relevant to user entities' internal control over financial reporting, intended for those user entities and the CPAs who audit their financial statements. Payroll feeds wages, taxes and liabilities straight into the customer's books, so payroll providers commonly issue SOC 1 reports, and their customers' external auditors read them. Change management over the payroll calculation code sits squarely in that scope.

SOC 2, in the AICPA's words, is a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy, measured against the Trust Services Criteria. HR platforms that do not process payroll, such as applicant tracking or benefits enrollment, usually lead with SOC 2.

Neither report says "SBOM". Both test controls an SBOM program produces evidence for: identifying vulnerabilities in the components you run, managing changes to production code, and assessing the vendors you depend on. The practical consequence is simple. If your service auditor samples a quarter and asks how you knew a critical vulnerability affected you, when you fixed it and who approved the exception, your supply chain program is the answer.

Two cautions for buyers: a SOC report covers a period and scope the vendor chose, and it does not cover the complementary user entity controls your own team must run.

The Nacha Operating Rules for ACH payroll

Most US payroll moves over the ACH Network, so any payroll provider that originates or transmits ACH entries on behalf of employers is bound by the Nacha Operating Rules through its bank agreements. Nacha calls these parties Third-Party Senders and Third-Party Service Providers.

Two rule changes matter for software:

• Supplementing Data Security Requirements. Large non-bank Originators, Third-Party Service Providers and Third-Party Senders must render deposit account numbers unreadable when stored electronically. Phase 1 took effect on 30 June 2021 for parties above 6 million ACH payments a year; Phase 2 took effect on 30 June 2022 for those above 2 million. Nacha says the rule is neutral on method and lists encryption, truncation and tokenization among the options.
• Fraud Monitoring. Under Nacha's 2026 risk management amendments, Originators, Third-Party Senders and Third-Party Service Providers must establish and implement risk-based processes reasonably intended to identify ACH entries initiated due to fraud. Phase 1 took effect on 20 March 2026 for all ODFIs and for non-consumer Originators, senders and service providers whose 2023 volume exceeded 6 million entries. Phase 2 took effect on 19 June 2026 for the rest.

Neither rule mentions open source, but both depend on software you build: the encryption and tokenization libraries that keep account numbers unreadable, and the logic that flags a suspicious direct deposit change. A vulnerable library in that path is a Nacha problem as well as a security one.

Department of Labor cybersecurity guidance for benefit plans

The Department of Labor's Employee Benefits Security Administration (EBSA) issued cybersecurity guidance in April 2021, including tips for hiring a service provider with strong security practices and a list of cybersecurity program best practices. EBSA's Compliance Assistance Release 2024-01 later clarified that the guidance applies to all types of ERISA plans, including health and welfare plans, not only retirement plans.

For benefits administration and retirement platforms, this matters because the hiring tips tell plan sponsors to ask service providers about their information security standards, practices, policies and audit results, and to write breach notification timing into the contract. The best practices list includes a formal, well documented cybersecurity program, annual risk assessments, a reliable annual third-party audit of security controls, a secure system development life cycle program, and security reviews of assets or data managed by a third-party service provider. Expect those questions at renewal.

HIPAA for benefits data

Under 45 CFR 160.103, a health plan is a covered entity, and a group health plan is an employee welfare benefit plan in the ERISA sense. A business associate is a person that creates, receives, maintains or transmits protected health information on a covered entity's behalf, for functions that include claims processing or administration and benefit management. That describes many benefits administration and enrollment platforms. Section 164.302 says a covered entity or business associate must comply with the Security Rule, and 164.308(a)(1) requires an accurate and thorough risk analysis and risk management measures that reduce risks and vulnerabilities to a reasonable level. In practice that means knowing which systems and components hold electronic PHI and keeping them patched. Carrier feeds and enrollment systems usually fall inside that scope.

The CCPA and California's new regulations

The California Consumer Privacy Act's exemptions for employment-related personal information and business-to-business data expired on 31 December 2022, according to the California Privacy Protection Agency. The CPPA's FAQ says California residents include employees, job applicants and contacts for independent contractors, so their HR and payroll data is in scope.

On 23 September 2025 the CPPA announced that regulations on cybersecurity audits, risk assessments and automated decisionmaking technology (ADMT) were approved, effective 1 January 2026. Businesses required to complete cybersecurity audits must submit certifications by 1 April 2028 if revenue exceeds 100 million dollars, 1 April 2029 if it is between 50 and 100 million, and 1 April 2030 below that. ADMT requirements for significant decisions begin on 1 January 2027, which matters for hiring tools that screen or rank candidates.

SEC cybersecurity disclosure rules

Public HCM vendors and public employers are covered by the SEC's 2023 rules. A registrant must disclose a material cybersecurity incident on Form 8-K Item 1.05, generally within four business days of determining it is material, and describe its processes for assessing, identifying and managing material cybersecurity risks, and its governance of them, in its annual report. A payroll vendor's incident can trigger the materiality analysis at many customers at once.

Federal guidance you can borrow

None of these binds a private HR tech company by itself, but customers and auditors recognise them:

• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, for secure development practices, including protecting the software, producing well-secured software and responding to vulnerabilities.
• NIST SP 800-161 Revision 1 (Update 1), for cybersecurity supply chain risk management practices across the enterprise and in vendor relationships.
• CISA's 2026 Minimum Elements for a Software Bill of Materials, published on 29 July 2026, which replaces the 2021 minimum elements as the reference for what an SBOM should contain. Use it to write the SBOM clause in your vendor contracts.

Real public incidents from the last three years

The incidents below come from official advisories and the affected companies' own statements. We draw no conclusions about what any organization should have done beyond what the sources say.

Mass data theft through a managed file transfer zero day (May 2023 onward)

CISA and the FBI reported that beginning on 27 May 2023 the CL0P ransomware group exploited CVE-2023-34362, a previously unknown SQL injection vulnerability in the MOVEit Transfer managed file transfer application. Internet-facing instances were infected with a web shell the advisory calls LEMURLOOT, which was used to steal data from the underlying databases. The advisory notes the same group had run similar zero day campaigns against other file transfer products before.

The advisory does not single out an industry. It matters here because managed file transfer is how a great deal of payroll and benefits data moves: payroll files to banks, enrollment files to carriers, census files to recordkeepers, often through a vendor's instance rather than your own. The lesson is narrow and practical: know every file transfer system that holds your data, including the ones your vendors run, and be able to confirm within hours whether any of them is affected.

A self-replicating worm in the npm registry (September 2025)

On 23 September 2025 CISA warned of a widespread supply chain compromise in npmjs.com, the JavaScript package registry. A self-replicating worm publicly known as Shai-Hulud compromised more than 500 packages, according to CISA. The malicious code scanned for credentials such as GitHub tokens and cloud API keys, exfiltrated them, and spread by publishing compromised versions of other packages as the compromised developer. CISA advised a dependency review including lock files and nested dependencies, pinning to known safe releases from before 16 September 2025, rotating developer credentials, and phishing-resistant multi-factor authentication on developer accounts.

Most employee portals, recruiting sites and admin consoles in HR tech have JavaScript front ends with deep npm dependency trees. An event like this is a build pipeline question first: which builds pulled an affected version, and which releases shipped it.

A vendor CRM accessed through social engineering (August 2025)

On 15 August 2025 an HCM software company disclosed that threat actors had accessed some information in its third-party CRM platform during a social engineering campaign targeting many large organizations. In that campaign, callers and texters pretended to be from human resources or IT to trick employees into giving up account access. The company said the information obtained was primarily commonly available business contact information, such as names, email addresses and phone numbers, that there was no indication of access to customer tenants or the data within them, and that it will never contact anyone by phone to request a password.

It belongs in this guide because of its shape: the entry point was a third-party SaaS platform connected to the vendor, not the core product, and the lure impersonated HR. Your vendor inventory should include your vendors' own vendors.

What the incidents have in common

• The entry point was software the victim bought or depended on, not software it wrote: a file transfer product, a package registry, a connected SaaS platform.
• Time to answer "are we affected?" decided the cost. Teams with an inventory answered in hours; teams without one answered in weeks.
• The blast radius ran through integrations. Payroll and benefits data moves between many parties, and an incident at one becomes a notification problem for many.

The personas who own the problem

Supply chain security in HR tech is shared between the vendor that builds the software and the employer that buys it. The table summarizes who needs what and when; the subsections explain each role.

The CISO

For a payroll vendor's CISO, the board's question is concentration risk: how many customers would one incident touch, and how fast can we tell them? For an employer's CISO it is the reverse: which HR vendors would put employee SSNs and bank details in a breach notice? Both need a current inventory, a patch clock with named owners and an incident timeline they could defend. The trigger is usually someone else's incident and a board request to confirm "we are not affected" by Friday.

The VP or Director of Engineering or Platform

Engineering in HR tech runs on release trains around fixed pay dates, with freezes before year-end and open enrollment. This persona needs one path for dependency updates that works during a freeze: a rule for which findings break the build, a short list of who approves an emergency change, and fix pull requests that pass the payroll regression suite. A second review queue or a weekly spreadsheet loses them.

The GRC or SOC lead

The SOC lead lives by the audit period. The service auditor samples changes, vulnerabilities and vendor reviews from that period and asks for the ticket, the scan, the approval and the date. Customer questionnaires ask the same things in renewal season. This persona needs evidence by control and an exception register with expiry dates and approvers.

The HRIS and payroll operations lead at the employer

This person knows the 401(k) feed runs on Tuesdays and the carrier file goes out on the 15th. When a vendor sends a breach notice, they can say which data the vendor held. They need an integration inventory: each connection, its data fields, its credential and the vendor-side owner. They rarely own security tooling, but they own the facts security depends on.

The procurement or vendor risk owner

The vendor risk owner needs coverage and continuity across the HR vendor list. For each vendor: the latest SOC report and its period, bridge letters for the gap, the subprocessor list, an SBOM or at least a component disclosure for critical systems, contract clauses for incident notice and vulnerability remediation, and a contact who answers within a day. For benefit plan vendors, the DOL's tips for hiring a service provider give a ready-made question list. The triggers are renewals and incidents.

Step by step: a 30, 60 and 90 day plan that works with any tools

The plan assumes a payroll or HR tech vendor, with notes for employers. It works with spreadsheets and open source tools as well as commercial platforms.

Days 1 to 30: see what you run

1. List the systems in scope. Start with the table in this guide. For each system, record whether you build it, buy it or both, which data classes it holds (SSN, bank account, health, biometric) and which regulation pulls it in.
2. Generate SBOMs for everything you build. One per deployable application and container image, in SPDX or CycloneDX. Include the payroll engine, tax and document generation services, the employee app, the admin console and the integration layer. Store them with the build, not on a laptop.
3. Inventory your vendors and integrations. For every vendor that touches employee data, record the data fields, the connection type (API, SFTP, iPaaS, SSO), the credential, the owner on each side and the latest SOC report date. Put file transfer systems at the top.
4. Match components against known exploited vulnerabilities. Run the SBOMs against the CISA Known Exploited Vulnerabilities catalog and an EPSS score. That gives you a first, short list of what matters now.
5. Name owners. Every application and every vendor gets a named owner. No owner means no fix.

Template for the vendor inventory:

Days 31 to 60: control what changes

6. Write the patch clock. Decide the remediation target for each class of finding and publish it. A starting point many teams adjust:

7. Put the clock in the pipeline. Add a policy check to CI that blocks the top row, warns on the second and notifies on the rest. Start in report-only mode for two weeks so teams see the volume before anything breaks.
8. Write the freeze rule. Decide in advance which findings may break a payroll freeze, who approves an emergency change, and what regression tests must pass. Write it down before year-end, not during it.
9. Run an exception process. Every finding you will not fix on time gets a recorded exception: justification, compensating control, approver, expiry date. This is the register your SOC auditor will sample.
10. Tier vendors. Critical (holds SSN or bank data, or moves money), high (holds other employee data), medium and low. Request SBOMs from critical vendors for the systems you depend on, and set review frequency by tier.
11. Fix contract gaps. Add or update clauses for incident notice timing, vulnerability remediation timing for critical findings, SBOM delivery, and subprocessor change notice. For benefit plan vendors, compare against the DOL's service provider tips.

Days 61 to 90: prove it works

12. Map evidence to controls. For SOC 1 and SOC 2, map your SBOM records, scan history, gate results, exception register and vendor reviews to the controls your auditor tests for vulnerability management, change management and vendor risk.
13. Rehearse a vendor incident. Pick a past event, such as the file transfer campaign above, and run a tabletop: which vendors use that product, which of your data they hold, who calls them, what you tell customers, and how long each step took.
14. Measure. Track time from disclosure to "we know if we are affected", time from finding to fix by tier, the count of open exceptions past expiry, and vendor coverage (critical vendors with a current SOC report and an SBOM on file).
15. Report. One page for the board or leadership: exposure by tier, the trend, the open exceptions and the vendor gaps. One evidence pack for the auditor.

Illustrative scenario: a critical CVE in a document library during year-end

This is an invented example with round numbers. In early December, a critical vulnerability is published in an open source PDF library. A payroll provider uses that library in the service that renders pay stubs and W-2 forms. Year-end freeze starts in a week.

With an inventory, the platform team finds the library in two of its 40 services within an hour. One parses uploaded documents (reachable); the other only renders internal templates. The freeze rule lets a reachable critical with a fix break the freeze with the VP of Engineering's approval. The fix runs the payroll regression suite and ships two days later, and the exception for the second service is recorded with a January expiry. The GRC lead files the timeline as audit evidence. Without an inventory, the team spends the first week searching repositories in the busiest month of the year.

How Safeguard does this

Everything above works without Safeguard. This section shows the same plan in Safeguard, using only flows from docs.safeguard.sh. Every capability named here is generally available (GA). Commands are copied as the docs show them; we did not run them for this post.

1. Inventory the software you build

Safeguard's Enterprise Software Supply Chain Manager (ESSCM, GA) generates SPDX and CycloneDX SBOMs (SBOM generation and analysis, GA) and runs software composition analysis (SCA, GA) across each project's full transitive dependency tree. Per the docs, you connect repositories or container registries through Integrations, or upload files, and Safeguard creates the project and its SBOM. Continuous scanning re-evaluates projects when vulnerability feeds change, so a new KEV entry is matched against existing SBOMs without a new build.

If a cloud service may not clone your payroll code, the local runner (GA) built into the Safeguard CLI (GA) runs scan jobs on your own machine and uploads only the SBOM and findings, never source code, over outbound HTTPS. The docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# start the interactive terminal, then type /login
safeguard

For a server without a terminal UI, the docs show:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

Safeguard also offers on-prem and fully air-gapped deployment (GA) and Zero AI mode (GA), in which the platform runs with no large language model in the loop. Both suit providers whose customer contracts restrict where employee data and code may go.

2. Prioritize by exploitation and reachability

Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your application calls the vulnerable code path. Together they fill the patch clock table. SAST (GA) covers your own payroll and integration code, DAST (GA) tests targets you have verified, such as a staging employee portal, and license compliance (GA) flags obligations in the components you ship to customers.

3. Turn the patch clock into policies and gates

Policies, gates and guardrails (GA) put the clock into the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions (severity, CVSS, EPSS, license, component age, maintenance) in the visual builder or YAML, and set severity and actions.

Each policy has one action that decides what a failure does to the gate:

A reasonable mapping: Block for KEV-listed or critical vulnerabilities with a fix in services that hold SSN or bank data, Warn for high, Notify for the rest. The docs show this GitHub Actions workflow:

name: Safeguard
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

Drop --fail-on critical for report-only mode in the first weeks, or add --fail-on-gate all to fail on a policy gate. The key is created under Settings › Developer with the scans:trigger and scans:read scopes. Policy outcomes are switched on per workspace, so confirm yours first.

4. Run exceptions through a recorded approval

Approval runs through exceptions. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a justification and an expiration date, and submits; approvers decide and the audit trail records it. That is the freeze rule from step 8 of the plan, recorded.

For findings you will not fix yet, the Mitigations tab records the type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), justification, approver, an optional expiry for risk acceptances, and evidence. That is the SOC lead's exception register.

5. Fix faster where a fix exists

Autonomous remediation (GA) opens fix pull requests that move a vulnerable dependency to a fixed version, singly or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on. The pull requests go through your normal review and your payroll regression suite like any other change, which keeps them inside SOC 1 change management.

6. Bring vendors inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) is where the vendor risk owner works. Per the docs:

1. Vendors › Add Vendor records the company, contact, products used and risk tier (Critical, High, Medium, Low), with CSV bulk import for a register that started in a spreadsheet. Contract records hold dates, SLA terms, security requirements and SBOM obligations.
2. Request SBOM, or Bulk Request for many vendors, sends a template setting SPDX or CycloneDX format, required fields and a deadline. Status moves from Sent to Validated or Rejected, with automated reminders around the deadline.
3. An arriving SBOM is validated for format and completeness and scanned for vulnerabilities; Request Revision returns one that falls short.
4. Monitoring alerts on new critical vulnerabilities and CISA KEV additions affecting a vendor's SBOM, and re-assessment can trigger on contract renewals and security incidents. Reports export as PDF or Excel.

The docs suggest quarterly SBOM updates for critical vendors and annual for high-risk ones, which fits the vendor tiering in step 10.

7. Map the evidence to SOC 2 and other frameworks

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, the framework library includes SOC 2 Type 1, SOC 2 Type 2 and the HIPAA Security Rule. You open a framework on Compliance › Frameworks, and its Connectors tab shows which connected systems answer its tests. Tests run on schedule or with Run now on Compliance › Tests, once the Safeguard team switches automated tests on for your workspace. The docs say a passing result is evidence toward a control, not proof that it is met.

Portal audit trails (GA) log SBOM activity, access and administrative changes. Per the docs, you view them on Settings › Audit Logs and export as CSV, JSON or PDF for the evidence folder.

8. Answer your customers once

Payroll and HR vendors answer employer security questionnaires all year, with a peak at renewal. Trust Center (GA) publishes a page with your compliance status, controls, policies, subprocessors and documents. Per the docs, you manage it on Compliance › Trust Center and publish explicitly; nothing goes live on its own. Portal (GA) handles sharing the SBOMs you choose to publish to customers.

What Safeguard does not do

• It is not your service auditor. Safeguard collects and organizes evidence. A CPA firm issues the SOC 1 or SOC 2 report, and your management writes the assertion. A passing test in Safeguard is evidence toward a control, not an opinion on it.
• It does not make account numbers unreadable. Nacha's data security rule is met by encryption, tokenization or truncation in your own systems. Safeguard can tell you whether the libraries doing that work carry known vulnerabilities; it does not encrypt your data.
• It does not monitor ACH entries for fraud. Nacha's fraud monitoring rule is about payment behavior. Direct deposit change controls, anomaly detection and bank partner coordination stay with your payments and fraud teams.
• It does not patch vendor-hosted systems. When the vulnerable code sits in a vendor's hosted file transfer service, carrier portal or time clock firmware, the fix has to come from that vendor. TPRM helps you track and chase it.
• It does not decide legal obligations. Whether HIPAA, the CCPA, state biometric laws or the SEC rules apply, whether an incident is material, and what goes in a breach notice are decisions for your counsel and leadership.
• It does not secure your HR SaaS configurations or identities. Access reviews in your HCM tenant, SSO and SCIM settings, and social engineering defenses are separate controls you still run.

Common mistakes

• Treating the vendor's SOC report as the whole answer. Check the period, the scope and the complementary user entity controls, and ask for a bridge letter when the period ended months ago.
• Leaving file transfer out of the inventory. It is the system type most often at the center of this industry's incidents, and it is often owned by an operations team rather than IT.
• Freezing everything at year-end. A freeze with no written exception path turns a critical CVE into either an unapproved change or a month of exposure. Decide the rule before December.
• Gating on severity alone. A build that fails on every high finding gets bypassed. Use KEV status, EPSS and reachability to decide what blocks.
• Forgetting the employee app. The self-service portal is where direct deposit changes happen.
• No owner for integrations. Every connector to a carrier, recordkeeper or bank needs a named owner on both sides, or nobody rotates its credential.

FAQ

What is software supply chain security for HR tech and payroll?

It is knowing, controlling and proving the security of every component and vendor behind your HR and payroll systems, and fixing what is vulnerable on a clock you can show an auditor.

Does a SOC 2 report require an SBOM?

No. The Trust Services Criteria do not name SBOMs. They test vulnerability identification, change management and vendor risk, and an SBOM program is one of the clearest ways to produce evidence for those controls.

Why do payroll providers issue SOC 1 reports instead of only SOC 2?

Because payroll affects customers' financial statements. A SOC 1 report addresses controls relevant to user entities' internal control over financial reporting, which their external auditors rely on. Many providers issue both.

Do the Nacha fraud monitoring rules apply to payroll companies?

They apply to Originators, Third-Party Senders and Third-Party Service Providers, which often includes payroll providers that originate or transmit ACH entries for employers. Phase 1 took effect on 20 March 2026 for parties whose 2023 volume exceeded 6 million entries, and Phase 2 on 19 June 2026 for the rest. Confirm your status with your ODFI.

Is employee data covered by the CCPA?

Yes, for California residents. The CPPA says the exemptions for employment-related personal information expired on 31 December 2022, and that California residents include employees and job applicants.

What should an employer ask its payroll vendor about software supply chain security?

Ask for the latest SOC 1 and SOC 2 reports and their periods, how the vendor tracks components and vulnerabilities in its software, its remediation timelines for critical findings, whether it can provide an SBOM for the systems you depend on, which file transfer and subprocessors handle your data, and how fast it will notify you of an incident.

Does the DOL cybersecurity guidance apply to health plans?

Yes. EBSA's Compliance Assistance Release 2024-01 says the April 2021 cybersecurity guidance applies to all types of ERISA plans, including health and welfare plans.

How should a payroll provider handle a critical CVE during year-end freeze?

Use a freeze rule written in advance: which findings may break the freeze (for example KEV-listed or reachable critical vulnerabilities with a fix), who approves the emergency change, which regression tests must pass, and how the exception is recorded for audit.

Can Safeguard scan payroll code without sending it to the cloud?

Yes. The local runner in the Safeguard CLI scans on your own machine and uploads only the SBOM and findings, and Safeguard also supports on-prem and air-gapped deployment and Zero AI mode.

The plan above tells you what is vulnerable and how fast it must be fixed; the harder part in a payroll freeze is getting the fix itself. Most open findings in an HR tech stack are open source dependencies with a published fix, and the rest are components where upstream has not shipped one yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session: ask "fix the lodash CVE in this repo", and the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. An employee portal team would use the same flow on its own repository, with the payroll regression suite in place of npm test.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. It is the route for payroll teams whose customer contracts do not allow a cloud service to clone their code.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. A GRC lead preparing for an audit sample could use the same connection to ask questions about findings in plain language.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• The Kronos ransomware attack and payroll
• Software supply chain security for SaaS
• Software supply chain security for financial services
• SOC 2 Trust Services Criteria explained
• MOVEit breach impact assessment
• Third-party risk management for software vendors

Sources

• CISA and FBI: CL0P ransomware gang exploits CVE-2023-34362 MOVEit vulnerability (AA23-158A)
• CISA: Widespread supply chain compromise impacting npm ecosystem (23 September 2025)
• Nacha: Supplementing Data Security Requirements
• Nacha: Risk Management Topics, Fraud Monitoring Phase 1
• California Privacy Protection Agency: California finalizes regulations (23 September 2025)
• California Privacy Protection Agency: Frequently asked questions
• AICPA and CIMA: SOC 1, SOC for Service Organizations: ICFR
• AICPA and CIMA: SOC 2
• US Department of Labor, EBSA: Compliance Assistance Release 2024-01
• US Department of Labor, EBSA: Cybersecurity program best practices
• US Department of Labor, EBSA: Tips for hiring a service provider with strong cybersecurity practices
• 45 CFR 160.103 definitions (Legal Information Institute text of the CFR)
• 45 CFR 164.302 applicability (Legal Information Institute text of the CFR)
• 45 CFR 164.308 administrative safeguards (Legal Information Institute text of the CFR)
• SEC: SEC adopts rules on cybersecurity risk management, strategy, governance and incident disclosure (26 July 2023)
• Workday: Protecting you from social engineering campaigns, an update from Workday (15 August 2025)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• NIST SP 800-218: Secure Software Development Framework version 1.1
• NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices
• Safeguard docs: Policies and Gates
• Safeguard docs: Mitigations
• Safeguard docs: Generate SBOM
• Safeguard docs: Continuous Scanning
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: SOC 2 and connectors
• Safeguard docs: HIPAA Security Rule and connectors
• Safeguard docs: Local Runner
• Safeguard docs: GitHub Actions
• Safeguard docs: Portal Audit Trails
• Safeguard docs: Trust Center setup

To try the flows in this guide, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.