Outsourcing software development from Maryland

Maryland outsourcing at a glance

This is a procurement triage, not a coverage determination. The Maryland Attorney General states that MODPA took effect October 1, 2025 and gives current scope and business guidance. Thresholds, exemptions, role, data type, processing purpose, sector rules, and the actual relationship still require current, fact-specific review.

Establish applicability before turning privacy words into controls

The Maryland Attorney General’s current business FAQ says MODPA applies to people doing business in Maryland or targeting products or services to Maryland residents that met either of two prior-calendar-year data thresholds: at least 35,000 Maryland consumers, or at least 10,000 Maryland consumers plus more than 20% of gross revenue from selling personal data. It also says processors serving covered businesses are within the framework and identifies exemptions and excluded data.

Do not reduce that description to “Maryland company equals covered” or “small project equals exempt.” Build a short applicability record with the operating entities, consumer context, prior-year volumes, revenue path, data categories, purposes, exemptions, sector overlays, controller and processor roles, and source date. Record uncertainty and obtain qualified advice before relying on an exemption.

Employment-context information is not the same consumer context described by the Attorney General’s MODPA FAQ. A Maryland employer outsourcing recruiting, payroll, monitoring, or workforce AI should not force that project into a consumer-privacy template. It may raise other employment, discrimination, security, contractual, sector, or destination-country issues. Create a separate review lane.

Keep Maryland’s Personal Information Protection Act analysis separate too. The Attorney General’s business guidelines discuss safeguards, third-party service contracts, disposal, and breach preparation for relevant personal information. MODPA does not erase those questions. The buyer’s control register should identify which source supports each control instead of using one generic “Maryland compliant” label.

Convert the requested product into a data budget

Maryland’s current Attorney General guidance describes a collection limit tied to what is reasonably necessary and proportionate to provide or maintain a specific product or service requested by the consumer. It says reasonable consumer expectations inform that analysis. That makes the product request a useful procurement boundary.

For each feature or service, create a data-budget card:

1. the product or service the person requested;
2. the user action and expected outcome;
3. each proposed raw field, document, message, image, event, identifier, location, prompt, and derived value;
4. why that item is necessary for the requested outcome;
5. a less-data alternative and why it is insufficient;
6. whether the item is sensitive data or creates another elevated-risk path;
7. collection source, system, environment, supplier, model host, and subprocessor;
8. access roles, local-copy and export rules, log behavior, and training-use position;
9. retention trigger, deletion or de-identification method, exception, and evidence;
10. approving owner, legal or privacy review, version, and next review date.

Treat “it may improve the model” as a hypothesis, not a purpose. The provider should show the feature, evaluation, and data relationship, and the buyer should decide whether the improvement justifies the field. If synthetic, de-identified, sampled, masked, or buyer-executed processing can achieve the pilot objective, test that path first.

The budget should be executable. Apply schema allowlists, API contracts, collection controls, role-based access, environment boundaries, log filtering, retention automation, and egress monitoring consistent with the decision. A spreadsheet that approves five fields while the supplier receives an unrestricted production export is not a control.

Put sensitive data behind a stricter stop gate

The Attorney General’s MODPA page lists sensitive categories including genetic or biometric data, a child’s personal data, precise geolocation, consumer health data, and data revealing specified personal characteristics. It says sensitive data may not be sold and may only be collected, processed, or shared when strictly necessary to provide or maintain the specific requested product or service.

Before an international team touches a candidate sensitive field, stop the ordinary intake and ask:

• Which official definition and actual facts place the field in or outside the category?
• What precise requested product function fails without it?
• Can the outcome use a less sensitive representation, shorter retention, on-device step, buyer-controlled service, or no collection?
• Which people, accounts, regions, logs, backups, evaluation tools, model providers, and subprocessors would receive it?
• What notice, consent, rights, assessment, security, discrimination, age-related, health, biometric, or sector analysis applies?
• How will the buyer prevent sale, unapproved reuse, model training, recombination, and uncontrolled derivation?
• How will a correction, deletion, incident, suspension, and exit propagate?

Do not let a supplier decide the field is “anonymous” because a name was removed. Linkability, derived data, remaining identifiers, small populations, free text, images, and supplier-held keys can change the analysis. Record the actual transformation and residual linkability, then obtain qualified review.

The Montana outsourcing guide shows why a multi-state product cannot reuse this gate unchanged: Montana separately routes minors-related feature assessments and covered genetic or neurotechnology data through consent, processor, current destination-screening, and outside-U.S. transfer controls.

Assess the activity before the algorithm runs

The Maryland Attorney General says a controller must conduct a data protection assessment for processing activities presenting heightened risk, including each algorithm that presents such risk. It identifies targeted advertising, sale, sensitive-data processing, and certain profiling as examples in the broader controller-obligation summary.

Build an algorithm and processing register before a provider selects a model or deploys a feature. For each activity, record the version, purpose, people, decision or effect, input data, inferred values, output, human role, distribution, foreseeable harm, consumer expectation, rights path, vendor chain, evaluation, monitoring, and retirement plan. Then determine with qualified reviewers whether and how the statutory assessment duty applies.

An assessment should be capable of changing the project. Complete it before the risky processing begins, with enough time to remove data, alter the purpose, add a safeguard, change the provider, narrow the population, preserve a meaningful human decision, or stop. A generic model card or vendor security report cannot substitute for the buyer’s use-specific analysis.

Set change triggers. A new model, data category, threshold, purpose, output recipient, user group, subprocessor, region, or automated action may invalidate the prior record. Require the supplier to notify the buyer before implementing the change and provide the evidence needed for reassessment.

Keep processor authority narrower than implementation freedom

The Attorney General explains that a processor acts at a controller’s request and direction under their contract, and that a processor can become a controller if it begins exercising decision-making authority over processing. A capable provider still needs engineering freedom; it does not need silent permission to invent new data purposes.

Write instructions that identify:

• the requested outcome and approved purposes;
• permitted data categories and prohibited sources;
• approved systems, environments, regions, accounts, and people;
• whether prompts, content, telemetry, and outputs may be retained or used for model training;
• subprocessor proposal, objection, and flow-down process;
• security, confidentiality, access, logging, review, and incident requirements;
• rights-request and assessment assistance;
• change notice and approval before a new purpose or recipient;
• return, deletion, residual retention, and evidence at exit;
• escalation when an instruction is unclear, unsafe, infeasible, or inconsistent with law.

Test the authority boundary in procurement. Give the provider a tempting product shortcut that requires an unapproved production field or third-party AI service. A strong team stops, documents the request, offers lower-data alternatives, and waits for the named buyer decision. A weak team optimizes for speed and explains the new data path after deployment.

Design Eastern-time delivery around named authority

Use the Maryland buyer’s actual city and an IANA identifier—commonly America/New_York—with the proposed provider cities and project dates. Daylight transitions differ across jurisdictions. Recalculate rather than treating “Eastern time” as a permanent UTC offset.

Create separate shared windows for product decisions, data-budget approval, sensitive-data review, architecture, release acceptance, and incident command. Teams in Latin America may provide broad same-day overlap for many city pairs. European teams can align with a Maryland morning and continue later. Asia-Pacific teams can support follow-the-sun delivery when the work package and authority are complete. Evaluate named people, their normal schedules, holidays, and backup coverage.

Every handoff should state the accepted outcome, current artifact, approved data budget, evidence produced, open risk, blocked decision, responsible person, deadline, and next authorized action. The supplier should not add a field, purpose, model, or subprocessor because the Maryland owner is offline.

Use urgency tiers. A routine design question can wait for the shared window. A suspected data event needs a secure 24-hour route with named primary and backup owners. Test both routes before production.

Choose the engagement model and control plane

A freelancer can fit a bounded prototype using synthetic or approved low-risk data when the buyer owns architecture and continuity. Staff augmentation can fit when the Maryland buyer can direct and inspect data decisions, delivery, security, and quality. A managed provider can fit a defined outcome when it supplies a named accountable lead and accepts explicit evidence duties. The commercial label does not decide the privacy role.

Write a responsibility matrix for product purpose, data budget, role analysis, sensitive-data gate, assessment, architecture, model choice, rights, security, release, monitoring, incidents, acceptance, and exit. Name a person on each side. “Shared” without a final decision owner is an unowned obligation.

Keep source repositories, cloud tenants, identity, package registries, model and evaluation accounts, domains, analytics, backups, and recovery methods under buyer governance. Use individual least-privilege access, protected branches, reviewed changes, reproducible releases, current runbooks, and tested offboarding.

Only then compare destination countries. Verify the contracting entity, named team and cities, employment or subcontracting relationships, data and tool locations, transfer and sector constraints, holidays, infrastructure, intellectual-property chain, continuity, and complete cost. Geography does not waive a Maryland control or prove a team can meet it.

Evaluate delivery, security, and ownership evidence

Ask the named team to walk through a comparable change from request to operation: decision record, data-budget card, threat or misuse analysis, code or configuration, peer review, tests, secure-development checks, release evidence, monitoring, incident response, and handover. NIST’s Secure Software Development Framework can structure questions, but evidence must fit the actual system.

Separate buyer background material, provider background material, new deliverables, open-source and commercial components, data, prompts, model configuration, evaluation sets, documentation, and operating records. Verify assignments or licenses through every employee and subcontractor in the relevant countries. WIPO’s directory can locate official destination-country intellectual-property offices; it does not prove the proposed chain is complete.

Require a software bill of materials or equivalent component inventory when appropriate, dependency and vulnerability practices, secret handling, change approval, backup and recovery evidence, incident contacts, and a usable exit package. Do not accept a badge as evidence that the named team and exact service operate as described.

Calculate complete cost, not the hourly-rate headline

Normalize proposals for the same accepted outcome and responsibility allocation. Include labor, delivery leadership, buyer coordination, privacy and qualified legal review, assessment work, data minimization engineering, security evidence, cloud and model usage, travel, currency, taxes or fees, rework, support, transition, and replacement.

Account for buyer decision latency. A distant team may deliver effectively with disciplined written work and protected overlap; an apparently convenient schedule may still stall if no owner can approve data or releases. Measure accepted outcomes, buyer hours, decision wait, defects, unapproved data-path changes, rights-test success, incident escalation, schedule sustainability, and exit readiness.

Model downside. Ask what happens if the provider adds a telemetry service, a prompt contains sensitive content, an algorithm changes after assessment, a subprocessor cannot delete an export, or the provider leaves before handover. Price the prevention, response, and recovery path.

Run a Maryland data-budget pilot

Use synthetic or approved nonproduction data. Give the named team a small product outcome and a proposed schema containing necessary, optional, excessive, and potentially sensitive fields. Require the team to create the data-budget card, challenge unnecessary collection, map recipients and copies, identify assessment questions, configure the approved path, and produce release evidence.

Midway through the pilot, request a feature that would be easier with a new field and unapproved AI service. Observe whether the provider stops and proposes alternatives or silently expands the path. Submit a test correction and deletion through the implemented systems. Confirm that logs, support tools, models, subprocessors, and retained copies behave according to the approved design.

End with a continue, revise, or stop decision. Do not scale if the named team did not participate, the purpose is vague, the data budget is not enforced, sensitive data bypasses review, an assessment cannot affect design, supplier tools remain undisclosed, critical accounts are provider-owned, or exit evidence is incomplete.

Maryland buyer red flags

• The proposal says “MODPA compliant” without identifying entity, threshold, exemption, role, data, purpose, or reviewed date.
• The provider wants a full production copy before it can define the requested feature.
• “Better analytics” or “model improvement” replaces a product-specific necessity argument.
• Sensitive data is identified only after it reaches logs or a model provider.
• A generic algorithm policy replaces an activity-specific heightened-risk assessment decision.
• The provider can add telemetry, training use, regions, or subprocessors without approval.
• The contract labels the supplier a processor while product practice lets it choose purposes.
• Eastern-time coverage depends on a salesperson rather than named delivery and incident roles.
• The buyer owns deliverables on paper but not repositories, accounts, keys, build instructions, or recovery.
• Exit means an email saying “deleted” without a reconciled copy and retention record.

Frequently asked questions

Does MODPA apply to every Maryland business or outsourcing project?

No. The Attorney General describes thresholds, roles, exemptions, excluded data, and consumer context. Determine coverage from the current law and actual entities, prior-year activity, data, purpose, and relationship with qualified counsel; do not infer it from a Maryland address or project label.

Can a provider collect extra data in case it becomes useful?

That is a poor default for a covered path. Maryland’s official guidance ties collection to what is reasonably necessary and proportionate for a specific requested product or service. Require a purpose and field-level decision before access.

Does every algorithm require a Maryland data protection assessment?

The Attorney General says each algorithm presenting a heightened risk requires assessment; it does not say every algorithm is automatically heightened risk. Inventory the real activity and obtain qualified review before processing.

Is a processor allowed to choose technical implementation details?

Yes, within approved instructions and the actual role. Engineering judgment does not require authority to invent new purposes, recipients, or training uses. Define the boundary and change process in the contract and system controls.

What is the best outsourcing country for a Maryland company?

There is no universal best country. Define the outcome, data budget, Eastern-time authority, skills, security, engagement model, complete cost, rights chain, destination constraints, continuity, and exit, then compare named teams using the same evidence model.

Is Outsourcing.ai located in Maryland?

No local presence is claimed. This is an online buyer guide, not a Maryland office, local-business listing, or representation of local employees or clients.

When the same buyer also supports a federal or defense contract, continue with the Virginia contract-inheritance guide to separate ordinary personal data from FCI, CUI, covered defense information, export-controlled material, and the systems authorized to handle each package.