Blog

What NYC Local Law 144 means for your technical hiring process

Amichai Shamah

If software helps you decide who moves forward for a job in New York City, someone on your leadership team will eventually ask about Local Law 144 of 2021. The city agency that publishes the overview and takes complaints is the Department of Consumer and Worker Protection. This article is a map for a hiring leader. It is not legal advice, not a compliance opinion, and not a substitute for counsel who knows your tools, your locations, and your candidate flow. Read the city page, then ask your lawyer whether your process is in scope.

The official summary is short, which is useful. On the NYC DCWP automated employment decision tools page, DCWP states that Local Law 144 prohibits employers and employment agencies from using an automated employment decision tool unless the tool has been subject to a bias audit within one year of the use of the tool, information about the bias audit is publicly available, and certain notices have been provided to employees or job candidates. DCWP also notes that enforcement of the law and its rules began on July 5, 2023. Those three conditions — audit, public information, notice — are the spine of the requirement as the city describes it.

Who the law is talking to

The city page addresses employers and employment agencies that use an automated employment decision tool. It does not address every piece of software in a recruiting stack by name, and a hiring leader should not guess the boundary from a vendor blog. A coding assessment, a ranking model, a resume screen, and a human recruiter using a spreadsheet can sit in very different places relative to the definition in the statute and the rules. Counsel makes that call. Your job, before that conversation, is to be able to say what the tool does in the process: whether it screens people out, ranks them, or only informs a person who decides.

Technical hiring is where this gets concrete. A take-home that a human reads is a different workflow from an assessment that scores candidates and advances only those above a line. Both can involve software. Only some uses will be the uses your counsel treats as an automated employment decision tool. Write the workflow down in plain sentences. Which roles, which stage, what the candidate is asked to do, what the score is used for, and who is allowed to override it. That paragraph is the brief your lawyer actually needs. A product name is not a brief.

A bias audit, at hiring-leader altitude

At this altitude, a bias audit is an independent check that has to exist before you rely on the tool, and the city page ties it to within one year of the use. It is not a sentence in a sales deck that says the model is fair. It is not your vendor promising that demographic fields are absent from the feature list, though that design choice still matters for a different reason. An audit looks at the tool as used. The rules, not this article, specify how the auditor calculates results. Do not treat a blog post as the instruction sheet for those calculations.

What you can do without waiting for a legal memo is make an audit possible. An auditor needs a defined tool, a defined use, and records that can be tied to that use. If the score is a black box, if every reviewer applied a private rubric, or if you cannot say which candidates were assessed with which version of the task, the audit becomes an exercise in reconstructing history. That reconstruction is where hiring teams lose months. The practical failure mode is not a dramatic lawsuit on day one. It is a process nobody can explain when DCWP, a candidate, or your own counsel asks for the file.

DCWP tells people they can complain when an employer or employment agency used an automated employment decision tool but did not make sure the required bias audit was done, did not post a summary of the results, or did not give the required notices. That complaint framing is a useful checklist for an operator even before counsel finishes the applicability analysis. Audit done. Summary posted. Notices given. If you cannot point to each one, you do not have a story. You have a gap.

The published summary and the notice

Public information means a summary of the bias audit can be found, not that a PDF exists in a shared drive. The city page describes the duty as information about the bias audit being publicly available, and the complaint language specifically includes failing to post a summary of the results. A hiring site that says assessments are fair, with no summary and no date, is not the same artifact. Put the summary where a candidate can open it, and keep the link from rotting after the next website redesign. Someone on the talent team should own the URL the way they own the careers page.

Notice is the condition recruiting teams most often discover too late. DCWP states that certain notices must be provided to employees or job candidates. In its educational materials, the agency clarified that the notice must be provided 10 business days prior to use of an automated employment decision tool. A typical technical screen sends the assessment link the same day a recruiter likes a resume. If your counsel concludes the law applies, that same-day link is an operational problem, not a copywriting problem. The calendar of the invite is part of the control. Confirm the contents of the notice with counsel. The city page is the starting point, and the rules sit behind it. This article will not invent a notice template.

How SkillFoundry records help a team prepare

SkillFoundry does not replace your auditor, your notice, or your published summary. The employer or employment agency remains responsible for those duties. We say that plainly because a vendor who implies otherwise creates risk for the customer. Local Law 144, as DCWP summarizes it, is a condition on using the tool. Buying software does not complete the condition. Preparing the records makes the condition achievable. Those are different sentences, and only the first one belongs to the city. The second one is a product claim, and it has edges.

The product claim is this. Bias-audit tooling is built in. Scoring operates on work products and session behavior: the code, the tests, and how the work was done. Demographic attributes are not inputs to any score. The same rubric applies to every candidate on a task, and each attempt stays pinned to the scoring profile version it was scored with. Task content is reviewed by a named person before it is published. None of that is a bias audit of your employment decisions. It is the shape of a system an auditor can examine without first reverse-engineering a spreadsheet.

The evidence trail is the part compliance teams actually open. Per-candidate score breakdowns, session evidence, and logged manual review give you a record of what was scored and what a human changed. That is the difference between the model said 82 and a file that holds the ticket, the submitted code, the tests, the rubric version, and the reviewer who advanced the candidate. Structured human review keeps a person accountable for the final decision. A data processing agreement, covering SkillFoundry as a processor of candidate data, is available to customers on request. Ask for it during procurement, not after a security questionnaire has already stalled.

We are equally explicit about what is not finished. SkillFoundry has not published an independent adverse-impact study of its own, and a vendor essay is not a bias audit of your use. If counsel decides Local Law 144 applies to a workflow, you still commission the independent audit, you still publish the summary, and you still give notice on the schedule the rules require. Our records exist so that work has something to stand on. The full account of this posture, including what we will not imply about SOC 2, is on the Trust and Compliance page.

A sequence a hiring leader can run

You do not need to become the lawyer. You do need to stop treating the assessment as a link you paste into an email and forget. Name the decision the tool participates in. Name the population, and remember that Local Law 144 is a New York City law. Where candidates reside and how the role is structured are questions for counsel. Put the bias audit on a calendar the city page can be read against: within one year of use. A pilot that quietly became production is how the year expires without anyone noticing.

Write notice into the process, including the 10 business day point DCWP has clarified, and keep a copy of what you sent. Publish the summary where a candidate can find it. Keep the evidence for the hire and for the rejection. When someone asks why one candidate advanced and another did not, the answer should be in the product, not in a recruiter memory of a Thursday panel. Memory is not a control. A logged review is a control. The difference matters the first time a candidate, an auditor, or your own board asks for the basis of a decision.

Start with the primary source. The DCWP page on automated employment decision tools is the city description of the law, the enforcement date, the complaint grounds, and the notice timing clarification. Then read how SkillFoundry describes its own limits and its evidence model on Trust and Compliance. Bring both to counsel. This is not legal advice. It is a hiring leader brief so that the legal conversation starts from the city page and from a record you can actually produce.

Read the compliance posture in full

Bias-audit tooling, a data processing agreement, and logged review are described on the trust page. The legal duty stays with the employer.