A Software Company in Massachusetts That Follows One Record Through Your Stack

Updated November 2026 · Written and maintained by the Progression Agency strategy team

A sales rep in Worcester exports a customer list to a laptop to work on the train, and the list holds names with driver’s license numbers for Massachusetts residents. Under the state’s data security regulation, 201 CMR 17, that file is personal information, and a laptop copy has to be encrypted. The same record also passes through a web form, a database, a backup and at least one vendor. A software company in Massachusetts building for a business like that follows one record through every hop before it writes code. Progression is based in New York, builds for Massachusetts companies remotely, and offers on-site sessions on request.

A spreadsheet of license numbers on a sales laptop

The file is called customers_export, it has a long run of rows, and it sits in a Documents folder on a laptop that rides the commuter rail every morning. Three of those rows are shown below with the numbers blanked.

The sample is a hypothetical, and the problem in it is ordinary. A resident’s name together with a driver’s license number is personal information under the state’s regulation, and the regulation requires personal information stored on laptops and other portable devices to be encrypted.

• Find every export button and every scheduled report in the system.
• Ask who receives each file and where it is saved.
• Decide whether the file needs to exist at all.
• If it does, make the laptop copy encrypted by design, not by habit.

What a software company in Massachusetts must know about 201 CMR 17

The regulation is 201 CMR 17.00, the state’s standards for the protection of personal information of residents. Under section 17.02, personal information is a resident’s first name and last name, or first initial and last name, together with one of three things: a Social Security number, a driver’s license or state ID number, or a financial account or card number that would permit access to the account.

The regulation applies to a person that owns or licenses such information, which it defines as receiving, storing, maintaining, processing or otherwise having access to it in connection with providing goods or services or with employment. A service provider is anyone permitted access through services provided directly to a person subject to the regulation.

Section 17.03 requires a written comprehensive information security program with safeguards appropriate to the size, scope and type of business, the resources available, the amount of stored data and the need for security. Section 17.04 lists the technical elements for electronic records, to the extent technically feasible.

Does the regulation reach companies outside Massachusetts?

It applies to persons that own or license personal information about a Massachusetts resident. Whether it reaches your business is a question for counsel.

Does “to the extent technically feasible” excuse a gap?

The phrase qualifies the technical elements in 17.04, and what is feasible is a judgment for the business and its counsel. Write the reasoning down in the program.

One record, hop by hop

Here is one hypothetical record, traced through ten hops. The first column names the hop, the second the 17.04 element or 17.03 duty that bears on it, the third what the software does, and the fourth what the written program says.

Forms and APIs: encryption in transit

Section 17.04(3) calls for encryption of all transmitted records and files containing personal information that travel across public networks, and of data transmitted wirelessly. In software terms, that means encrypted connections on every form, every API call and every mobile screen that sends the record.

Laptops and exports: encryption at rest

Section 17.04(5) calls for encryption of all personal information stored on laptops or other portable devices. The better design is an export that never needs to exist, since a file that was never created cannot be lost.

Admin panels: unique logins and lockouts

Section 17.04(1) and (2) call for control of user IDs, secure password handling, access for active users only, blocking after multiple unsuccessful attempts, and unique IDs with passwords that are not vendor supplied defaults.

The statement of what the regulation requires ends there. Whether a particular system meets it is a question for counsel, and nothing on this page says any system does.

The written program in plain words

Section 17.03(2) says the program must include, without limiting its generality, a set of named items. Here they are, each with a plain reading and the thing a software team can build for it.

• Read the program against the table once a year.
• Keep each item tied to a named person.
• Change the table when the regulation or your business changes.
• Take any doubt about an item to counsel.

Vendors in the path

A business that owns or licenses personal information must oversee its service providers. Section 17.03(2)(f) says to take reasonable steps to select and retain providers capable of maintaining appropriate security measures, and to require them by contract to implement and maintain those measures.

• List every vendor that can see or store a covered record.
• Keep the list beside the data map, and update both together.
• Read each contract for a safeguard clause, or ask counsel to.
• Remove any vendor that no longer needs the data.
• Keep personal information out of tools that do not need it.

This page draws no legal conclusion about any contract. The vendor list is the starting point for counsel.

Which vendors do small teams forget?

The analytics script on the form page, the support desk that takes attachments, the backup service and the email platform. Each can hold a copy of a record that no one meant to send.

Leavers and their access

Section 17.03(2)(e) requires preventing terminated employees from accessing records containing personal information. In software, that is an offboarding step wired to the accounts, not a ticket someone remembers to file.

• Tie every account to a person in the staff list.
• Disable access the day the person leaves, from one switch.
• Review the account list monthly against the staff list.
• Remove shared logins, since they cannot be tied to a person.

What about contractors and temps?

Section 17.03(2)(b) names ongoing employee training, including temporary and contract employees. Give contractors accounts that expire.

Monitoring that a small team can actually read

Section 17.04(4) calls for reasonable monitoring of systems for unauthorized use of or access to personal information. A small team can read a short alert about the records that matter better than a long log about everything.

• Alert on a bulk export of customer records.
• Alert on repeated failed logins to the admin panel.
• Alert on access to the table at unusual hours.
• Send alerts to a named person with a backup.

This page claims no standard beyond the regulation’s own words. The alerts are a design suggestion, and counsel decides what is reasonable for your business.

How long should logs be kept?

The regulation does not give a period in the sections discussed here. Ask counsel, and keep logs long enough to answer a question about last quarter.

Public records and what falls outside

Section 17.02 excludes information that is lawfully obtained from publicly available information, or from federal, state or local government records lawfully made available to the general public. A name taken from a public record is not personal information by itself.

A team still maps those fields, so nobody guesses later. A field that came from a public record and a field that came from a customer look the same in a database, and a data map that records the source avoids an argument in the middle of a review.

• Record the source of each field: customer, public record or third party.
• Keep public record data apart from customer data where practical.
• Do not assume an exclusion applies; ask counsel.
• Update the map when a new source is added.

What if a record mixes both?

Treat the whole record as covered until counsel says otherwise. A name from a public record joined to a license number from a customer is a different thing.

The yearly review, scheduled in the system

Section 17.03(2)(i) requires reviewing the scope of the security measures at least annually, or whenever there is a material change in business practices that may reasonably implicate the security or integrity of records containing personal information. Put that date in the system, with an owner.

Our software development company page describes how we plan and build. For healthcare data, see HIPAA compliant software development, and for Boston buildings and apps, app development in Boston.

What mapping and building this costs

The map comes first and the build follows from it. Here are the published US bands for the build work. Hosting, licenses and security testing are on top.

Progression quotes after a written scope and publishes no Massachusetts price. See fintech software development for financial account data.

Related services and guides

Pages that sit beside this one:

• Software development company
• HIPAA compliant software development
• Fintech software development
• Software company in Boston
• Government software development

Frequently asked questions