B2B Software Consulting in Minneapolis
Minnesota’s Consumer Data Privacy Act took effect on 31 July 2025 and asks for two things no other state had: a data inventory, and the right to be told why a profiling decision came out the way it did. ERPStack is remote-first — we build that explanation into the Minneapolis ERP audit trail in PostgreSQL on AWS, not into a policy page.
Quick Answer
In short: Minnesota's Consumer Data Privacy Act has been in force since 31 July 2025 and demands a data inventory plus an explainable profiling decision. ERPStack builds a Minneapolis ERP to it, with Minn. Stat. §144.293 health-record consent, Government Data Practices Act handling, running in AWS us-east-2 with the us-east-1-msp-1a Local Zone.
Regional Compliance
- Minnesota Consumer Data Privacy Act (Minn. Stat. §§325M.10–325M.21)
- Minnesota health records consent rules (Minn. Stat. §144.293)
- Minnesota Government Data Practices Act (Minn. Stat. ch. 13)
- FDA Quality Management System Regulation (21 CFR Part 820, ISO 13485:2016)
- Minnesota Paid Leave premium reporting (Minn. Stat. §268B.14)
- HIPAA, SOC 2 Type II and PCI DSS control mapping
Security & Compliance Architecture
HIPAA, SOC 2 Compliance and PCI DSS are the floor for a Minneapolis ERP; every vendor clears them. The argument is the Minnesota Consumer Data Privacy Act, Minn. Stat. §§325M.10–325M.21, in force since 31 July 2025 — a statute asking two things no other state asked, and both land in the Minneapolis schema.
§325M.14(g): a Minneapolis profiling decision must be explainable
Where profiling drives a decision with legal or similarly significant effects, the Minnesota consumer may question the result, must be told the reason, may review the personal data used and — if it was inaccurate — may have it corrected and the decision reevaluated. You get 45 days, extendable once by 45, and subd. 5 requires an appeal path. A Minneapolis ERP needs decision lineage in PostgreSQL, not an outcome column; multi-tenant SaaS makes that harder, since lineage stays tenant-scoped.§325M.16 wants a data inventory; §325M.18 wants a documented assessment
§325M.16 subd. 2(c) requires security practices “including the maintenance of an inventory of the data”, and §325M.18 requires a data privacy and protection assessment the Minnesota attorney general can demand. Penalties reach $7,500 per violation, and the 30-day cure paragraph in §325M.20 expired on 31 January 2026. We keep the Minneapolis inventory in PostgreSQL and alert on drift through Sentry and GitHub Actions.Minn. Stat. §144.293 is stricter than HIPAA
A Minnesota provider may not release a health record without a signed and dated patient consent, and subd. 4 makes that consent valid for one year unless the release sits inside subd. 6. HIPAA would permit that disclosure for treatment or payment with no authorisation, so hipaa compliant software alone is not enough for Minneapolis healthcare: consent needs an expiry, a scope and a revocation path in PostgreSQL. Minneapolis government work adds the Minnesota Government Data Practices Act, ch. 13, presuming data are public unless classified.Minnesota payroll changed on 1 January 2026
Minn. Stat. §268B.14 subd. 6 sets employer premiums at 0.7 percent for both programmes, 0.4 percent medical-only and 0.3 percent family-only, capped at 1.1 percent, remitted quarterly from the wage detail report with the employer paying at least 50 percent. Earned sick and safe time accrues 1 hour per 30 worked to at least 48 a year, balances shown every pay period. Minnesota taxes corporate franchise income at 9.8 percent. Neither SAP S/4HANA nor Microsoft Dynamics 365 ships that Minneapolis ERP payroll configuration.
Engineering Blueprint
AWS runs no region in Minnesota. A Minneapolis ERP keeps its PostgreSQL primary in us-east-2, US East (Ohio), with the Local Zone US East (Minneapolis), us-east-1-msp-1a, for latency-bound edge work and Vercel serving Next.js from cle1, which maps to that same AWS region. Nothing in the Minnesota Consumer Data Privacy Act requires the data to sit in Minnesota — but §325M.16 requires you to know exactly where it does sit.
The Minneapolis data inventory is generated, never typed
Minn. Stat. §325M.16 subd. 2(c) requires an inventory of the data you manage, so for Minneapolis clients the AWS region, the PostgreSQL schema, the retention rule and the lawful basis are columns rather than a slide. We generate that inventory from Drizzle ORM schema metadata and Terraform state, diff it on every pull request through CI/CD Deployment Pipelines on GitHub Actions, and fail the build when a new Minneapolis table lands without a retention rule. A hand-kept inventory drifts inside one sprint; a generated one is evidence a Minnesota regulator or a SOC 2 auditor can read.
Profiling explainability as a Minneapolis table
Minn. Stat. §325M.14, paragraph (g), gives a Minnesota consumer the right to question the result of profiling, to be told the reason it produced that decision, and to have it reevaluated on corrected data. That is not a policy page; it is a row. A Minneapolis ERP stores the model version, input snapshot, reason code and reevaluation link behind RBAC, row-level security in PostgreSQL and an immutable audit trail, served over a REST API and typed end to end with Zod and TypeScript shared with the Next.js front end.
// Drizzle ORM + PostgreSQL — Minn. Stat. 325M.14(g) explainability
export const profilingDecisions = pgTable('profiling_decisions', {
consumerId: uuid('consumer_id').notNull(),
modelVersion: varchar('model_version', { length: 32 }).notNull(),
reasonCode: varchar('reason_code', { length: 64 }).notNull(),
inputSnapshot: jsonb('input_snapshot').notNull(),
reevaluatedFrom: uuid('reevaluated_from'),
});One Minneapolis event bus for retail EDI and medtech UDI
Minneapolis retail runs on X12: 850 Purchase Order in, 856 Ship Notice/Manifest out, 810 Invoice, 997 Functional Acknowledgment back, and a chargeback the moment the 856 misses its window. Target sits at 1000 Nicollet Mall and Best Buy in Richfield, so a Minneapolis supplier ERP carries vendor-compliance rules as versioned PostgreSQL data rather than tribal knowledge, with Redis fronting catalogue reads. The same Apache Kafka topics and Event-Driven Architecture carry Minneapolis medtech traffic — UDI records to GUDID under 21 CFR 830.300 — plus healthcare 837 and 835 claims for the payer cluster around UnitedHealth Group in Eden Prairie.
Evaluate Your Stack
Take our interactive audit to see if your architecture is ready for operational scale.
Start Free AuditRegional Infrastructure
Infrastructure Region
Latency Metrics
Primary Datacenter
Success Stories in Minneapolis
Field Operations & Compliance Portal
Unified operational portal for field tracking and compliance
Read Case StudyTarget Industries in Minneapolis
Frequently Asked Questions
Yes, at 100,000 it applies. Minn. Stat. §325M.12 catches a controller processing personal data of 100,000 consumers or more in a calendar year, or 25,000 where over 25 percent of gross revenue comes from selling data. Penalties reach $7,500 per violation and there is no private right of action, but the 30-day cure paragraph expired on 31 January 2026 — a Minneapolis SaaS or B2B Software controller now gets sued, not warned.
For a single-site Minneapolis device maker with straightforward assembly, Oracle NetSuite plus a validated eQMS is the cheaper honest answer. Custom ERP development wins when device history records, UDI submissions to GUDID and complaint-to-MDR workflows must share one PostgreSQL ledger with production. The FDA QMSR takes effect 2 February 2026, and retrofitting ISO 13485:2016 traceability into a bolted-on Minneapolis manufacturing system is the expensive path.
Treat vendor compliance as data. A Minneapolis retail supplier ERP ingests the X12 850 Purchase Order, emits an 856 Ship Notice/Manifest inside the retailer window, invoices on the 810 and reconciles the 997 Functional Acknowledgment. Chargeback rules — label format, carton counts, ASN timing — belong in versioned PostgreSQL tables behind a REST API, so a Minneapolis retail compliance change is a Drizzle ORM migration rather than a rewrite.
You can stay in us-east-2. The Minnesota Consumer Data Privacy Act imposes no data-residency rule, so a Minneapolis ERP runs its PostgreSQL primary in US East (Ohio) with the Local Zone us-east-1-msp-1a for edge work and Vercel serving Next.js from cle1. What §325M.16 does demand is that the inventory names the AWS region holding each data category — for multi-tenant SaaS, per tenant.
It means decision lineage. Minn. Stat. §325M.14(g) lets a Minnesota consumer question the result of profiling, demand the reason it produced that decision, review the personal data used and — where that data was wrong — have it corrected and the decision reevaluated. A Minneapolis ERP stores model version, input snapshot and reason code per decision in PostgreSQL, answers inside 45 days, and exposes the appeal path subd. 5 requires.
Minn. Stat. §325M.16 subd. 2(c) requires data security practices including maintenance of an inventory of the data being managed, and §325M.18 requires a documented assessment the Minnesota attorney general can demand. We generate the Minneapolis inventory from Drizzle ORM schema metadata and Terraform state so it cannot drift from the PostgreSQL tables it describes, and gate it in CI/CD Deployment Pipelines — a spreadsheet always drifts.
The FDA Quality Management System Regulation replaces the old Quality System Regulation in 21 CFR Part 820, incorporating ISO 13485:2016 by reference; the final rule published 2 February 2024 at 89 FR 7496 and takes effect 2 February 2026. For a Minneapolis manufacturer that pulls device history, UDI submissions under 21 CFR 830.300 and the 30-day MDR clock in 21 CFR 803.50 into one ERP with an immutable audit trail in PostgreSQL.
From 1 January 2026, Minn. Stat. §268B.14 subd. 6 charges 0.7 percent of taxable wages for employers in both programmes, 0.4 percent medical-only and 0.3 percent family-only, capped at 1.1 percent. Employers pay at least 50 percent and may deduct the rest per employee in proportion. Premiums are quarterly, from the wage detail report — so a Minneapolis ERP needs per-employee premium apportionment in PostgreSQL, not one deduction line.