New York City Local Law 144 is an all in one regime that combines annual bias audits and candidate notification in a single law. New York State split the obligations across two bills, one for disparate impact analysis and one for notice. The practical difference is sequencing, not scope, because the state approach aims to recreate the same compliance outcome through separate requirements.
Why the two laws feel similar but are structured differently
Both New York City Local Law 144 and the New York State AEDT bills try to address the same underlying problem: automated employment decisions can produce discriminatory outcomes even when the system appears neutral on paper. The difference is legislative design. NYC packages the obligations into one compliance regime, while the state bills split the same policy goal into separate statutory duties.
The practical effect is that organisations should think in terms of a single control outcome, then map it to two different legal pathways. That matters because teams often build one process for bias analysis and another for candidate notice, and the law determines whether those steps must be documented together or administered separately.
This is a compliance architecture issue more than a substantive policy disagreement. The decision point is whether the organisation needs one integrated workflow with a single audit-and-notice cycle, or a divided workflow where each obligation is satisfied under its own rulemaking and timing.
What changes operationally between the city regime and the state bills
Under the city model, the main operational burden is coordination. Bias audit results, candidate notices, vendor oversight, and publication or disclosure requirements need to be aligned so that the organisation can show a coherent control story. Under the state approach, the same control story is often rebuilt in parts, which can create timing mismatches if one bill becomes effective or interpreted differently than the other.
That sequencing difference is important for employers, vendors, and counsel because it affects how quickly a hiring tool can be deployed, what evidence must be retained, and which internal team owns each step. If a process assumes one combined checkpoint, but the state framework expects separate checkpoints, the organisation can end up technically compliant in substance but out of sequence in practice.
For a broader governance lens, the relevant question is not whether the two approaches impose radically different substantive duties, but whether they force different compliance operations. In most real programmes, that means contract review, procurement gating, documentation retention, and candidate communications need to be designed for the strictest timing rule in the applicable jurisdiction.
How practitioners should compare them in practice
If you are comparing them for program design, focus on three things: whether the audit requirement is coupled to notice, whether the compliance artefacts are produced once or twice, and whether the law expects a single end state or a staged implementation. Those are the points that change staffing, workflow, and legal sign-off.
For organisations using vendors or shared employment technology, the comparison also affects oversight. A single law may let you centralise evidence collection, while split bills can require separate attestations or jurisdiction-specific templates. The safer approach is to design the control set once, then vary only the legal wrapper by jurisdiction.
One useful benchmark is the broader non-human identity and secrets governance problem: when controls are separated by function, teams often miss the handoff between analysis and notification. In an AI or automated decision context, the same structural risk appears if the audit is complete but the disclosure step is not operationalised.
Risk and Threat Considerations
When obligations are split across multiple bills, the main risk is control fragmentation. A team may complete the bias analysis but fail to trigger the notice process, or apply the notice template without preserving the evidence needed to defend the analysis. That creates compliance exposure even when each individual step exists somewhere in the organisation.
Failure mechanism: Separate legal duties can be mapped to separate owners, systems, and timelines, which increases the chance of missed handoffs, inconsistent documentation, or using the wrong process for the wrong jurisdiction.
Impact: The organisation can face enforcement, complaint handling problems, procurement delays, and avoidable reputational damage because it cannot demonstrate that both the analytical and disclosure obligations were satisfied in the right sequence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Applies because both laws change compliance sequencing and program risk management. |
| PR.DS-01 — Data is Managed | Applicable because audit evidence and notice artefacts must be retained and controlled across the workflow. | |
| GV.OC-02 — Roles, Responsibilities, and Authorities Are Established | Relevant because split obligations require clear ownership between legal, HR, procurement, and vendors. | |
| Recommendation — Align jurisdictional obligations to your risk management strategy and track sequencing gaps by control owner. Manage audit and notice records so the organisation can prove each required step was completed. Assign explicit ownership for audit, notice, and vendor oversight across jurisdictions. | ||
| CIS Controls v8 | 6.1 — Establish an Access Governance Process | Relevant because compliance programs need governed workflows, approvals, and evidence handling. |
| Recommendation — Use a governed process to approve, document, and review each compliance step. | ||
| NIST SP 800-63 | 1.1 — Identity Proofing and Enrollment | Applies where candidate notice and system accountability depend on correct subject identification. |
| Recommendation — Verify that the right subject and jurisdiction are tied to each notice and decision record. | ||
Practitioner Guidance
What to prioritise: Build one jurisdiction-aware workflow that records the audit result, the notice artefact, and the effective date for each applicable rule set. The goal is to prevent a split between “we did the analysis” and “we proved the notice.”
What to verify: Confirm that vendors can supply audit artefacts in a format your legal and HR teams can actually use, and that candidate-facing notices are versioned by jurisdiction. If those two outputs do not reconcile cleanly, the programme will be brittle under review.
Common mistake: Treating the city law and the state bills as if they are interchangeable because they pursue the same policy objective. The substance may be similar, but the compliance evidence and timing can differ enough to matter.
Practitioner takeaway: Design for the compliance outcome first, then map the sequence required by the applicable law, because most real failures come from process handoff, not from misunderstanding the headline policy.
Related resources from NHI Mgmt Group
- What is the difference between New York City Local Law 144 and the newer state-level AEDT bias audit approaches?
- What is the difference between global identity strategy and local governance?
- What is the difference between local account cleanup and full identity governance?
- What is the difference between local agent governance and enterprise agent governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
