Software built for New York companies, with the record a review asks for written as the work runs

The New York Department of Financial Services publishes a cybersecurity regulation, 23 NYCRR Part 500. It binds covered entities, which means firms licensed or registered with that department, rather than every company in New York. If you hold no such licence or registration, Part 500 does not reach you. None of this is legal advice about your situation.

Reading Part 500 as amended effective 1 November 2023: under section 500.17(b)(2) the annual filing is signed by the covered entity's highest-ranking executive and its chief information security officer. Two signatures, both personal, covering work an outside firm may have done most of.

Section 500.17(b)(3) adds a retention rule. Records supporting that filing are held for five years and made available to the department for examination on request. Nothing has to be scheduled for that request to arrive. Five years is longer than most engagements run, so the material has to still make sense to somebody who was never in the room when it was written.

A comment on Hacker News puts the same thing without the citation: in my experience, you are responsible, regardless. It doesn't matter who wrote the code originally.

The third row moves fastest. Since 1 November 2023 an incident at a third party service provider can start your own 72 hour clock under section 500.17(a)(1), and that clock runs from the point you determine an incident has occurred, not from the moment it happened. It does not catch everything: 500.1(g) names the kinds that count, which are the ones requiring you to notify a supervisory body, or with a reasonable likelihood of materially harming a material part of your normal operations, or deploying ransomware in a material part of your systems. The amendment narrowed this to that defined set rather than widening it to every event. You cannot see inside a provider's systems, so the notice term in the contract is the mechanism you control. Ask for that wording before you sign, because after an event it is somebody's goodwill. Note also that the duty here is yours throughout. No provider, us included, is bound by Part 500 on your behalf. Part 500 binds covered entities, which means firms licensed or registered with the Department of Financial Services, not every company in New York. None of this is legal advice about your situation.

None of that is written afterwards to satisfy a review. It is what the work leaves behind while it runs. Answering a questionnaire is then mostly a matter of finding the right file.

Code lives in your repositories. Deployments live in your cloud accounts. Any documentation we produce is yours to keep. If you offboard us, you keep everything, including the operational runbook. The reason for putting that on day one is the case nobody plans for, which is an engagement that ends early.

If you already have your own Git hosting, cloud accounts and storage, we work inside them. If you do not have them, we provision them, set them up, and hand you the keys. The accounts are yours either way, so there is nothing to negotiate about access later.

After launch there are two ways to keep going. An annual maintenance contract covers ongoing maintenance and growth work. A lean mode arrangement covers lighter ongoing support. Both run through the same change note process as the build.

One thing this is not. Neither Part 500 nor the SHIELD Act says anything about who owns the code, about source escrow, or about assigning intellectual property. Nothing above is required of us by New York. It is how we choose to work, and you should hold us to it on that basis rather than on a regulator's.

That is how we choose to work, and it is worth being exact about why. Neither Part 500 nor the New York SHIELD Act says anything about who owns source code. This is a commercial arrangement we offer, not a rule anyone imposed on us.

• Business hours are Monday to Friday, 10:00 to 19:00 IST.
• The most urgent issues, the ones we log as P1: four working hours.
• The tier below that, P2: twenty-four working hours.
• Everything else: seventy-two working hours.
• Those targets are for acknowledgement by a named person who engages with the issue, not for resolution. How long a fix takes depends on what the issue turns out to be. We do not commit to that.

One system built this way that a business runs on

RFID stock audits cut from a full weekend to ten minutes

We built the multi-tenant RFID platform an inventory software vendor sells to optical stores and other small retailers, then merged its separate scanning apps into one.

A stock audit that took two to three people a full weekend now takes ten minutes.

10 minFull stock audit, down from a whole weekend

5 daysMissing or misplaced stock found within five working days

1 appOne scanning app across three reader vendors

• #SaaS
• #Retail
• #RFID
• #Automation

View Case Study

What it does not prove: no New York regulatory review is a variable in our records of that work. Neither is a transition away from a previous vendor. It says nothing about how long the work took, in what order it ran, or what was built alongside it. It is evidence that the way of working above produces a system a business depends on, and nothing beyond that.

There are two shapes of engagement. A dedicated cross-functional team working inside your sprints, for multi-month work whose scope keeps moving. Or team formation on demand, for a specialist capability gap, a scale-up, or a vertical you cannot staff internally.

Scope is agreed in writing before anything starts. Every change after that goes through a documented change note, with time, effort and cost laid out before approval. Nothing in the build moves on a re-scope you have not explicitly accepted.

Four things move the size of the work. Which shape it is, how long it runs, what mix of skills it needs, and what the review on the other side asks for. Name those four in the first message and the first answer can be specific.