Outsourcing software development from Mississippi

Mississippi outsourcing at a glance

The rows are not interchangeable. “Public” State data is not permission to transfer a covered State dataset abroad. “Remote access” is not a synonym for an offshore development seat. An approved AI product is not approved for every purpose or data class. A clean security scan is not human authorization to publish or act on an AI result. A Secretary of State filing is not evidence of delivery quality. The execution membrane keeps those distinctions visible.

The core decision: what crosses the membrane?

The most useful Mississippi question is not simply “Can this provider work offshore?” It is: what exact object moves, in which direction, under whose authority, and what can it reveal or change? A design that says “the team uses our cloud” hides several different movements:

• State records may be copied into a hosted database;
• backups may replicate to another region;
• observability tools may export payloads or prompt content;
• a developer may download a production sample;
• an AI assistant may retain or train on a prompt;
• a support engineer may view a live record through a remote session;
• source, binaries, models, schemas, migrations, test results, and documentation may enter the buyer’s controlled environment;
• incident evidence and exit exports may need to return to the buyer.

Make each movement a row in a data-and-artifact manifest. Record the object, source, destination, storage and transit path, replica and backup behavior, people and service identities, purpose, authorization, retention, logs, deletion, incident route, and release owner. “No data transfer” is not proven if the error tracker sends payloads abroad or a model gateway logs prompts in a different region.

The membrane should have three operational modes:

1. Closed development mode. The international team works with public requirements, approved documentation, generated fixtures, synthetic records, mock services, and isolated build tools. No State data or account crosses.
2. Artifact admission mode. A versioned source or binary package, dependency manifest, model or prompt package where applicable, build provenance, tests, and known limitations enter a U.S.-controlled inspection environment. A named buyer reviewer accepts, rejects, or quarantines it.
3. Scoped support mode. A named person receives time-limited, least-privilege access solely for a required technical-support task under the applicable contract and security plan. The session is logged, supervised at the chosen risk level, produces a defined evidence packet, and is revoked.

If a proposed workflow cannot distinguish those modes, do not call it compliant, secure, or ready. Redesign it before comparing hourly rates.

Scope the State, ITS, and private-company lanes separately

Mississippi’s current materials do not create one rule for every organization with a Mississippi address.

The Enterprise Cloud and Offsite Hosting Security Policy applies to State agencies, State employees, trusted partners, and authorized entities operating, managing, or using State information and systems. It covers third-party-managed and hosted systems and requires the ITS-approved terms for cloud and offsite-hosting contracts. The applicable public- or nonpublic-data terms then control the actual hosted service.

The November 2025 AI policy is expressly an ITS-agency policy. Its scope includes ITS employees, temporary workers, contractors, and others authorized to use agency systems while they plan, pilot, develop, acquire, deploy, or interact with AI in ITS operations. Executive Order 1584 and the statewide inventory create broader State-government context, but a supplier should not silently rewrite an ITS policy as a universal private-sector statute or as automatic approval for another agency.

The Public Records Act applies to its defined public bodies and records. Section 75-24-29 has a separately defined private-business personal-information perimeter. Sector, federal, local, grant, insurance, health, education, criminal-justice, export, and customer requirements may add different controls.

Use an applicability memo with at least:

• the exact buyer and contracting entity;
• whether the work is an ITS operation, another State-agency system, another public body’s system, or ordinary private work;
• the executed solicitation, contract, amendment, and incorporated policies;
• the data owner, information owner, record custodian, security owner, AI approval owner, incident owner, and release owner;
• the service functions: development, hosting, operations, maintenance, support, AI use, records processing, or a combination;
• the systems, environments, countries, regions, accounts, people, subprocessors, and tools;
• the written scope or exception decision and its date.

An international provider may be suitable for one lane and ineligible for another. That is a work-package decision, not a nationality score.

Classify the data before choosing an architecture

The July 2025 Enterprise Security Policy requires each covered agency to establish a classification framework based on sensitivity and criticality. The framework covers data created, collected, accessed, owned, processed, maintained, stored, or transmitted by the agency, including access by employees, contractors, and third parties. Classification is a prerequisite for decisions about collection, generation, access, processing, storage, transmission, archiving, and disposal.

Do not reduce that exercise to “public” and “private” checkboxes in a vendor form. Build a field- and operation-level inventory:

• source and authoritative owner;
• public, nonpublic, confidential, privileged, regulated, or other buyer classification;
• identifiers, free text, attachments, images, recordings, logs, prompts, embeddings, model outputs, derived features, and joined datasets;
• permitted use and prohibited adjacency;
• system, environment, region, backup, cache, queue, analytics, support, and observability path;
• human and service identities with read, write, export, approve, delete, and administer actions;
• record status, retention, hold, redaction, and destruction rules;
• synthetic-fixture or transformation method and residual linkability;
• incident sensitivity and escalation owner.

A public website feed can still be State data under the cloud terms. Public availability does not erase ownership, integrity, access, location, logging, return, or continuity obligations. Conversely, a private Mississippi company’s public marketing data does not become State data merely because the company operates in Mississippi.

Treat derived and operational data as real data paths

Teams often protect the primary database but export its substance through side channels. Inspect:

• stack traces containing request bodies;
• screenshots and screen recordings;
• support tickets and chat transcripts;
• search indexes and vector stores;
• feature stores, evaluation sets, and model caches;
• analytics events and session replay;
• database snapshots, replicas, exports, and local developer dumps;
• CI logs, test reports, crash dumps, and telemetry;
• email, transcription, and meeting-note tools;
• backups and disaster-recovery copies.

For every channel, prove location, content minimization, access, retention, deletion, export, and incident behavior. “The production database is in Virginia” does not prove the full system stays inside the required boundary.

Keep State data, backups, and disaster recovery inside the U.S. boundary

Mississippi’s posted public-data terms and nonpublic-data terms both say the service provider shall not store or transfer State data outside the United States, including backup and disaster-recovery locations. This is a location rule for the data under those terms, not a blanket statement that every contributor must be in the United States.

Make the provider prove the complete topology:

Use policy-as-code where practical: approved-region controls, organization policies, infrastructure tests, storage replication checks, egress rules, DLP alerts, secret scanning, and continuous inventory. Retain human-readable evidence too. A dashboard that disappears with the vendor is not an exit record.

Do not confuse residency with remote access

The same terms permit provider personnel and contractors to access State data remotely only as required to provide technical support. That sentence creates a narrow operational distinction. It does not say that every remote activity is support, that support has unlimited access, or that a supplier may reproduce the data in another country.

Define “technical support” in the work order: affected service, ticket class, purpose, permitted operations, prohibited development or analytics use, named roles, escalation, access window, and expected evidence. Decide whether the actual task is diagnosis, configuration, maintenance, incident response, data repair, user support, deployment, or feature development. If the team plans routine backlog work against live State records, calling it support does not change the facts.

Build a narrow, logged technical-support aperture

For any approved remote support involving State data, create a session passport:

1. Trigger. Ticket, incident, maintenance event, or written State request.
2. Named identity. One individually assigned account tied to an approved person and employer; never a shared vendor login.
3. Purpose. The exact diagnosis or repair and the systems and records necessary.
4. Device and connection. Managed posture, approved VPN or circuit where applicable, MFA, encryption, no credential sharing, and the buyer’s network restrictions.
5. Authority. Read, query, execute, configure, restart, deploy, export, or delete permissions; privileged commands are separately bounded.
6. Data exposure. Fields, screens, rows, logs, attachments, and outputs visible to the support role.
7. Time. Start, expiry, renewal authority, and immediate-revoke path.
8. Observation. Authentication, queries, commands, changes, exports, errors, approvals, and supervisor events.
9. Closeout. Result, unresolved risk, files created, configuration changed, credentials revoked, local/session residue reconciled, and evidence returned.

The Enterprise Security Policy requires MFA for remote access, granular restrictions, agency-defined limits for remotely executed privileged commands and security-relevant information, individual accounts, and immediate revocation when the need ends. Translate those requirements into the actual identity provider, bastion, just-in-time role, query proxy, session recorder, and ticket workflow. A contractual sentence without an enforceable mechanism is not enough.

Support access should not create an unreviewed data export. Disable or control clipboard, file transfer, printing, local cache, screen capture, agent forwarding, and unapproved AI assistants according to the risk. If a diagnostic file must move, treat it as a separate transfer decision with minimization, location, recipient, retention, and destruction evidence.

Let artifacts travel through a clean-room delivery lane

An outside-U.S. team can still perform valuable architecture, application, automation, integration, testing, documentation, and AI-engineering work without receiving State data. The buyer must design for it.

The clean-room package can include:

• public statutes, policies, standards, schemas, and interface contracts;
• buyer-authored functional requirements with sensitive examples removed;
• synthetic datasets that exercise nulls, distributions, permissions, errors, scale, and adversarial cases without reconstructing real people or records;
• generated images, documents, audio, or events licensed and approved for the test purpose;
• mock services and contract tests;
• isolated repositories with only the code and documentation needed for the package;
• approved dependency, model, container, and build registries;
• threat models and misuse cases that describe risk without disclosing live weaknesses;
• acceptance fixtures maintained by the buyer inside the U.S. boundary.

The returning artifact should contain source, build instructions, dependency and component inventory, model and dataset references where relevant, tests, scan results, evaluation results, configuration schema, migrations, infrastructure definitions, known limitations, operational runbooks, accessibility evidence, release notes, rollback instructions, and license notices. Sign or otherwise bind the artifact to the version that was reviewed.

Inside the U.S.-controlled admission lane, the buyer should rebuild where feasible, verify provenance, run static and dynamic checks, inspect dependencies, execute representative acceptance and security tests against controlled data, validate migration and rollback, and require a human release decision. Test evidence created outside can inform that decision; it does not replace buyer-controlled verification against the real environment.

Synthetic data needs an acceptance test

“Synthetic” is not a magic label. Record how the fixture was created, whether real records seeded it, which distributions or rare cases it preserves, whether free text or attachments can leak source content, and what linkage or membership-inference tests were performed. Separate generated fixtures from masked or tokenized production extracts.

The buyer should maintain an internal acceptance set that the outside team cannot tune against. For AI, include ordinary, boundary, adversarial, fairness, accessibility, refusal, prompt-injection, data-leakage, and human-escalation cases appropriate to the use. Publish only aggregate or minimized results outside the protected lane.

Bind ITS AI to system, purpose, data, and human authority

The active ITS AI policy does not approve “AI” in the abstract. It requires approval for AI deployment, interaction, or use involving PII/nonpublic data or a high-risk system; approved systems may be used only for approved purposes. PII or nonpublic data cannot be entered into a nonapproved AI system, including through prompts. An approved system using that data may not train on it. Employees must review AI-created content before it is shared, published, or acted upon, and high-risk content or impacts require review and approval.

Create an AI use passport:

The policy defines high risk around health, safety, financial, security, privacy, fundamental rights, or consequential decisions. Do not make the provider the final high-risk or applicability authority. The provider supplies facts, testing, limitations, and controls; the authorized buyer owners decide.

The policy’s human-review requirement should produce evidence: source verification, uncertainty, conflicts, edits, reason for acceptance, responsible person, date, version, and action taken. A button labeled “approve” without the information needed to challenge the output is ceremonial oversight.

Screen model and tool changes continuously

The Prohibited Technology List is dated and updateable. Screen the actual developer, host, owner, affiliate, embedded SDK, model gateway, desktop application, browser extension, mobile package, device, and replacement tool. Keep the State-device and State-network perimeter distinct from the broader ITS AI policy’s foreign-adversary prohibition.

Do not infer that a contributor is prohibited because of citizenship or work country. The questions concern the named technology, legal and control facts, and the applicable system/device/network rule. A permissible contributor can use an impermissible tool; a U.S. supplier can embed one; a named product can change ownership or dependencies. Record evidence rather than stereotypes.

Secure the build and prove the release

Mississippi’s Enterprise Security Policy calls for a secure application-development process addressing secure design, coding, developer training, vulnerability management, third-party code, and application security testing. Use the NIST Secure Software Development Framework as a practical evidence structure where appropriate.

For each candidate release, collect:

• repository and branch protections;
• named contributors and service identities;
• commit, review, build, artifact, container, model, prompt, and configuration versions;
• dependency and license inventory, including transitive and AI components;
• secret, static, composition, infrastructure, container, and dynamic test results appropriate to the system;
• threat and abuse cases, including prompt injection, data extraction, insecure actions, privilege escalation, and unsafe fallback where AI is involved;
• remediation or accepted-risk decisions with named owners and expiration;
• reproducible build or provenance attestation;
• accessibility acceptance for public and workforce interfaces;
• deployment, monitoring, rollback, recovery, and decommission plans;
• a buyer-owned final release record.

Never expose live vulnerabilities to a broad project tool merely to prove that testing happened. Keep the public-safe delivery record separate from restricted findings, exploits, credentials, and incident evidence. Reference the protected record by stable identifier.

Preserve public access, redaction, and record custody

Mississippi’s Public Records Act says automation must not erode access to records electronically maintained. Before a public body acquires or materially modifies software used to store, retrieve, or manipulate a public record, it must plan for public access and redaction. A contract for creation or maintenance of a public-record database may not impair inspection or copying. The Act also addresses common-format electronic copies, segregating exempt from nonexempt material, written denials, and preservation of denial files.

For a supplier or AI platform, test record operations before launch:

• export a complete record in a usable common format;
• retain attachments, relationships, timestamps, authorship, version and approval state;
• search and collect by custodian, date, subject, identifier, and legal criteria;
• segregate and redact without altering the preserved source;
• document exemption and denial decisions outside the supplier’s black box;
• place and release legal or investigation holds;
• migrate records, metadata, audit history, and disposition state to a replacement;
• prove that provider termination does not destroy records during the protected transition;
• reconcile final return and lawful disposal.

An AI chat, prompt, output, evaluation, human review, meeting transcription, or decision-support record may become a public record depending on its use and facts. The ITS AI policy explicitly warns that AI use may create public records and requires applicable retention. Do not rely on a vendor’s default 30-day history or “ephemeral” mode as the buyer’s record determination.

Conversely, do not publish protected or exempt information because “AI records are public.” The custodian and qualified owners apply the actual law, exemptions, redaction, and retention schedule.

Build the incident relay before onboarding

The nonpublic State-data terms call unauthorized access or disclosure a security breach, require immediate provider notification, and coordinate communications with the State. The Enterprise Security Policy requires covered agencies to define incident roles, internal oversight of third-party work, primary and backup communication mechanisms, reporting, exercises, and post-incident review. That State contract and policy lane is separate from the private-business statute.

Mississippi Code section 75-24-29 applies to a person conducting business in Mississippi that owns, licenses, or maintains its defined personal information about Mississippi residents. Its maintainer path turns on discovery and specified acquisition-for-fraud facts; owner/licensor decisions involve investigation, harm, notice without unreasonable delay, restoration, and any law-enforcement delay. A supplier should relay facts immediately enough for the buyer to make those decisions, not wait to decide statutory applicability itself.

Use a progressive incident packet:

Maintain an out-of-band contact method because ordinary email or project systems may fail. Exercise a lost provider account, compromised AI token, prohibited-tool discovery, cross-border log misroute, inaccessible record export, and unavailable U.S. release owner. Test who can freeze support access and stop an automated action.

Apply a separate private-company control set

Private Mississippi buyers should not copy the State terms and call the result legal compliance. They can deliberately adopt useful controls—classification, U.S.-only processing, named support access, approved AI purposes, human release, logs, return, destruction—through contract and architecture, but should label those as buyer requirements unless another law or customer obligation applies.

Start with the actual private perimeter:

• data and customers involved;
• applicable federal, state, sector, customer, insurance, grant, export, and destination-country requirements;
• whether the buyer owns, licenses, or maintains defined Mississippi personal information;
• provider/controller/processor/maintainer and other roles under each applicable instrument;
• incident and notice authority;
• IP, employment, tax, payment, and contributor-assignment facts;
• commercial retention, litigation holds, deletion, and exit.

For section 75-24-29, preserve enough evidence to determine the definition of personal information, encryption or unreadable state, unauthorized acquisition, affected Mississippi residents, fraudulent purpose where the maintainer clause uses it, investigation, likely harm, and any law-enforcement delay. Do not promise a universal fixed notification clock that the cited general statute does not state.

Verify the provider, people, countries, and tools

Run diligence on the actual delivery chain, not the sales deck:

• exact contracting entity, formation jurisdiction, status, address, signatory, insurance, litigation and sanctions checks appropriate to risk;
• beneficial and operational ownership where necessary;
• named team, employer or contractor relationship, country, city, time zone, role, experience, availability, replacement process, and background-check path where contractually required;
• every subprocessor, affiliate, consultant, model provider, data center, support vendor, and material open-source or commercial dependency;
• accounts, devices, repositories, clouds, AI tools, communication systems, ticketing, monitoring, backup, and remote-support path;
• secure-development, incident, continuity, accessibility, privacy, data-location, record, and exit evidence;
• references only when permission and relationship are verifiable.

The Mississippi Secretary of State search can verify filing facts for a relevant Mississippi entity. It does not establish that the company employs the proposed people, controls an offshore affiliate, can access a named region, owns code, or performs well. Verify each proposition separately.

For contributors outside the United States, use the WIPO directory and qualified destination-country advice for local software, copyright, invention, moral-rights, employment, contractor, and assignment questions. Obtain signed instruments from the correct people and entities. “Work made for hire” in a U.S. template is not a substitute for jurisdiction-specific analysis.

Compare countries by work-package fit, not stereotypes

Mississippi buyers can source from Latin America, Europe, Africa, Asia, Canada, or elsewhere when the package fits the data, authority, clock, legal, security, skills, continuity, and cost requirements. The State-data membrane makes the architecture more important than a country ranking.

For each proposed team location, record:

• exact city and maintained IANA time-zone identifier;
• working overlap for the engagement dates, including clock changes at both ends;
• communication and decision-writing evidence for the role;
• legal entity, employment or contractor route, IP chain, and tax/payment operations;
• sanctions, export controls, customer restrictions, and data-transfer rules applicable to the facts;
• skills demonstrated through representative work;
• power, network, weather, political, platform, and personnel continuity;
• travel and replacement realities;
• complete cost and exit portability.

Mississippi operates on Central time, but the delivery city may change clocks on different dates or not at all. Store zones, not fixed UTC offsets. Use the IANA database to calculate the dated schedule. Name primary and backup release, security, incident, record, and support owners; do not rely on “Central-time overlap” as a proxy for authority.

Use asynchronous evidence, not permanent night work

A strong handoff contains the candidate version, completed work, test evidence, changed risks, unresolved questions, blocked decision, named owner, required answer, deadline, and safe default. A weak handoff says “please review” and leaves the next team to reconstruct context.

Reserve synchronous time for architecture, threat review, difficult debugging, acceptance, incidents, and relationship health. Measure sustained overlap and retention, not a proposal-week demonstration that depends on unhealthy hours.

Normalize complete cost around the membrane

An international hourly rate omits buyer-retained work and control-plane cost. Calculate:

complete cost = supplier delivery + buyer ownership + boundary engineering + security and record evidence + tools and infrastructure + transition risk + uncertainty

Include:

• discovery, architecture, data classification, applicability, and contract work;
• synthetic-data and mock-service creation;
• duplicate or U.S.-contained acceptance environments;
• identity, bastion, VPN, logging, DLP, region enforcement, key management, and audit tooling;
• AI approval, evaluation, human review, monitoring, and change control;
• security, accessibility, public-record, incident, recovery, and continuity tests;
• buyer product, technical, security, legal, procurement, data, record, and release owners;
• overlap, handoffs, translation, travel, payment, currency, and tax operations;
• rework, defects, dependency changes, provider turnover, and blocked access;
• return, migration, knowledge transfer, secure disposal, and replacement-provider cost;
• contingency for uncertain scope and policy change.

Compare options under the same work breakdown and acceptance standard. A U.S.-only team with weak records and exit may be riskier than a disciplined artifact-only international team; an inexpensive overseas team can become uneconomic if the buyer has to rebuild the entire boundary after selection.

Run a representative paid pilot

The pilot should exercise the operating system, not merely produce a polished demo. Choose one bounded feature or automation with meaningful interfaces, error cases, security checks, records, and rollback but no uncontrolled State-data exposure.

Require the team to:

1. turn an outcome into a work-package and data manifest;
2. build synthetic fixtures and document their limits;
3. work inside the isolated clean-room lane;
4. produce a reproducible, versioned artifact and evidence package;
5. pass buyer-controlled U.S. admission tests;
6. resolve a simulated defect through the narrow support process without broadening access;
7. handle an AI output or code path with source verification and human review if AI is in scope;
8. respond to a simulated incident with progressive evidence;
9. export a representative public record and perform a redaction test if public records are in scope;
10. roll back, return documentation and credentials, and complete a mini-exit.

Score outcome quality, evidence quality, security, data-boundary discipline, communication, prediction accuracy, sustainable pace, buyer effort, recovery, and portability. Do not score the pilot only on velocity.

Put the operating boundary in the contract schedule

The statement of work, security schedule, data schedule, AI schedule, records schedule, support schedule, SLA, and exit schedule should agree. Define:

• entities, people, roles, locations, systems, data, purposes, and environments;
• public and nonpublic State data and any buyer-specific classes;
• prohibited storage, transfer, replication, backup, DR, local download, logging, and AI paths;
• the clean-room inputs and permissible returning artifacts;
• technical-support definition, trigger, identity, access, supervision, logs, output, and revocation;
• approved AI system, purpose, data, training/retention setting, human authority, tests, monitoring, records, and change trigger;
• prohibited-technology screening and replacement;
• secure-development evidence and acceptance gates;
• subprocessor disclosure, approval or notice, and flow-down;
• incident trigger, immediate factual relay, update cadence, preservation, investigation, communications, recovery, and cost allocation;
• public-record access, redaction, export, hold, retention, denial, and migration;
• availability, maintenance, RTO, RPO, vulnerability management, support, and service credits where appropriate;
• ownership, licenses, contributor assignments, residual tools, third-party materials, and open-source obligations;
• suspension, 90-day protected transition where the State terms apply, return, secure disposal, destruction certificates, knowledge transfer, and survival terms.

Do not freeze a web-link snapshot into an ambiguous promise. Attach or identify the exact policy and term versions incorporated, define precedence, name the change-review process, and record who can accept a changed policy or exception.

Design exit before access

The public and nonpublic State terms describe orderly return in CSV, XML, or another mutually agreed format, continued security and backup during a 90-day post-termination period, and subsequent disposal; the nonpublic terms also call for NIST-approved destruction and certificates when requested. Operationalize that before signing.

Test:

• source and complete history;
• build and deployment automation;
• configuration, infrastructure, secrets inventory, and key transition;
• data and records with relationships, metadata, attachments, audit history, retention and hold state;
• model, prompt, retrieval, evaluation, monitoring, and approval artifacts;
• tickets, decisions, runbooks, architecture, threat models, incidents, known defects, and risk acceptance;
• account and credential revocation;
• backup and disaster-recovery disposition;
• return integrity and replacement-provider import;
• deletion across primary, replica, cache, log, support, backup, AI, and subprocessor paths;
• certificates and buyer acceptance of final state.

Keep a read-only buyer-controlled evidence copy that does not depend on the provider’s account remaining active. Resolve litigation holds, investigations, public records, and other required preservation before deletion. “Delete everything immediately” can conflict with preservation; “retain indefinitely” can conflict with minimization and contract. The named owners decide and document the lawful state.

Mississippi outsourcing red flags

• A provider says public State data may be hosted anywhere because it is public.
• A diagram shows a U.S. database but omits backups, disaster recovery, logs, AI, analytics, support, and subprocessors.
• Routine feature development against live State records is labeled “technical support.”
• Shared vendor accounts or standing administrator access replace named, expiring sessions.
• An overseas engineer can download records, screenshots, logs, or diagnostic files without a separate transfer decision.
• “Synthetic” fixtures were derived from production without provenance or leakage testing.
• An AI product is called approved without the exact system, version, purpose, data, configuration, reviewer, and date.
• A provider uses protected prompts or outputs for model training.
• Human review is a click without sources, uncertainty, correction, or authority.
• The prohibited-technology check covers only product names and ignores owners, affiliates, embedded components, and changes.
• The State policy is presented as a universal private-company rule.
• A private breach clause uses one invented deadline and removes the buyer’s investigation and notice authority.
• Public records cannot be exported with relationships, metadata, attachments, and audit history.
• The security report exists only in the provider portal.
• The quote excludes boundary engineering, U.S. acceptance, buyer owners, incident tests, and exit.
• The team promises permanent night-shift overlap without a retention and health plan.
• Subcontractors appear only after access begins.
• The contract promises return and destruction but no import or deletion test exists.
• A Mississippi filing record is marketed as proof of local staff, customers, capability, or State authorization.

Frequently asked questions

Can a Mississippi company outsource software development outside the United States?

Yes, when its actual legal, customer, security, data, IP, and operational requirements permit it. For covered State cloud or offsite work, design around the applicable Mississippi terms: State data remains inside the U.S. storage and transfer boundary, while an international team can work through an artifact-only lane and any remote technical support is separately scoped and controlled.

Do Mississippi’s State cloud terms apply to every private business?

No. They apply within their State-agency and contract scope. A private buyer may adopt the controls contractually, but should not label them universal Mississippi law without a real basis.

Can public State data be stored outside the United States?

The current posted public-State-data terms say the service provider shall not store or transfer State data outside the United States, including backup and disaster-recovery locations. Apply the executed contract and any current written decision; do not infer permission from public availability.

Does remote technical-support access allow offshore development on State data?

Not by label alone. The posted terms limit remote access by provider personnel or contractors to what is required for technical support. Define the task, person, account, purpose, data, permissions, session, logs, supervision, outputs, revocation, and residue. Ordinary feature development needs a different architecture or authority.

Can an international team develop a State system without State data?

Often, yes. Use public requirements, synthetic fixtures, mock services, isolated repositories, approved dependencies, and buyer-owned acceptance sets. Admit only a versioned artifact and evidence package into a U.S.-controlled inspection and release lane.

Does the Mississippi ITS AI policy apply to all State agencies?

The active policy text identifies itself as an ITS-agency policy and covers ITS users and operations, including authorized contractors. Executive Order 1584 and the inventory provide statewide context. Another agency should identify its own adopted policy, contract, and approval authority rather than assuming scope.

Can PII or nonpublic data be used with an AI system in ITS work?

Only through the policy’s approval and protection path. The exact system and purpose need approval; entering that data into a nonapproved system, including prompts, is prohibited; protected data in an approved system may not be used to train AI; access, encryption, testing, human review, records, monitoring, and other applicable controls remain necessary.

Is an approved AI tool approved for every task?

No. The policy binds approved systems to approved purposes. Recheck data, use, model or endpoint, configuration, users, autonomy, outputs, impact, and change before relying on an earlier approval.

Can AI make a final decision for ITS?

The policy says AI must not be solely relied upon for final decisions and must not replace employee judgment in ethical, critical, sensitive, or high-risk areas. Build meaningful, informed human review and preserve the decision evidence.

Are AI prompts and outputs Mississippi public records?

They can be, depending on the public body, use, and record definition. The ITS AI policy expressly notes that AI use may create a public record. Route the determination, retention, access, exemption, redaction, and disposal through the authorized custodian.

Does Mississippi’s prohibited-technology rule prohibit people from particular countries?

The cited State-device and State-network rule concerns prohibited technologies, and the ITS AI policy separately addresses AI systems developed, hosted, or owned by designated foreign adversaries. Screen actual technology, owner, host, affiliate, component, and applicable perimeter. Do not convert that into a nationality inference about contributors.

What should a supplier report during an incident?

Immediately provide time, system, identities, data, access or acquisition evidence, encryption/readability state, locations, logs, containment, current service effect, preserved evidence, unknowns, and the next update. The buyer retains classification, investigation, notice, regulator, law-enforcement, communications, recovery, and release decisions.

Does Mississippi have one fixed general breach-notification deadline?

The cited general private-business statute uses notice without unreasonable delay after the relevant investigation and restoration steps, subject to its harm and law-enforcement provisions; it does not state one universal number for every incident. State contracts, sectors, customers, and other laws can create faster or different paths. Contract for immediate factual escalation.

Which country is best for a Mississippi buyer?

There is no universal winner. Compare named teams and cities against the work package’s data boundary, skill, legal and IP path, dated Central-time overlap, communication, security, continuity, complete cost, pilot evidence, and exit. State-data work may require an artifact-only architecture regardless of country.

Is Outsourcing.ai located in Mississippi?

No local presence is claimed. This is an online buyer guide, not a Mississippi office, local-business listing, representation of local employees or customers, State authorization, procurement eligibility, or completed local work.

Mississippi buyer checklist

• Identify the exact buyer, public/private/ITS lane, contract, incorporated policy version, and qualified owners.
• Inventory data, records, prompts, outputs, logs, backups, DR, analytics, support, AI, and subprocessors.
• Classify data and define permitted purpose, location, access, retention, export, deletion, and incident path.
• Prove U.S. location for covered State primary, replica, backup, disaster-recovery, log, support, and AI paths.
• Separate clean-room development, artifact admission, and narrow technical-support modes.
• Generate and test synthetic fixtures without leaking or reconstructing real records.
• Use named accounts, approved connections, MFA, least privilege, expiry, logging, and immediate revocation for support.
• Bind AI to exact system, purpose, data, training setting, human review, tests, monitoring, records, and change triggers.
• Screen prohibited technologies, owners, affiliates, embedded components, tools, and material changes.
• Collect secure-development, dependency, license, build, scan, evaluation, accessibility, and rollback evidence.
• Test public-record search, common-format export, redaction, hold, retention, denial, and migration where applicable.
• Exercise progressive incidents, out-of-band contacts, buyer decisions, recovery, and post-incident review.
• Verify entities, people, employers, countries, subprocessors, tools, insurance, references, and IP assignments.
• Calculate dated overlap with IANA zones and name primary and backup authority owners.
• Normalize complete cost including boundary engineering, U.S. acceptance, buyer effort, controls, rework, and exit.
• Run a paid pilot that includes artifact admission, scoped support, incident, rollback, record export, and mini-exit.
• Contract the data, support, AI, security, records, incident, acceptance, IP, continuity, return, and disposal schedules.
• Rehearse source, build, infrastructure, data, record, model, account, credential, backup, return, and destruction handover.

Sources and maintenance

This guide prioritizes current Mississippi ITS policies and terms, the Ethics Commission’s statutory public-record compilation, the Secretary of State’s entity search, current published statutory text, and primary NIST, IANA, and WIPO operational references. It does not treat a State-policy summary, a vendor claim, or a search result as project approval.

Review before the stated date and sooner if Mississippi changes the AI policy or approved-use process, prohibited-technology list, Enterprise Security Policy, cloud/offsite policy, public or nonpublic terms, baseline controls, public-record rules, breach statute, State procurement clauses, or incident standards; if NIST revises the cited frameworks; or if a material provider, model, hosting, subprocessor, region, data, purpose, or ownership fact changes.

Build the membrane before buying capacity

The durable Mississippi model is a data-stays / artifacts-travel execution membrane. Covered State data, backups, and disaster-recovery copies remain inside their required U.S. boundary. An outside-U.S. team works against public specifications, synthetic fixtures, isolated tools, and approved components. A signed, versioned artifact crosses into buyer-controlled inspection. A separate, narrow support aperture opens only for a required technical task, named person, defined data, constrained authority, observed session, and immediate revocation. AI remains bound to system, purpose, data, evaluation, human judgment, records, and a stop path.

If a provider can prove that operating model through a representative pilot—and return source, evidence, records, credentials, and data through a tested exit—international delivery can expand capability without quietly exporting State data or buyer authority. If it cannot, do not scale the engagement.