JwumaWhat we actually do, not a badge
No formal third-party certification exists today. Rather than a row of badges that would overstate that, this page describes the specific mechanisms the platform actually runs, so your own security review can check a real claim against a real system.
Where we stand today
Corpshore AI does not hold SOC 2, ISO 27001 or an equivalent third-party certification today. What follows is the set of controls actually built and running, which a certification would formalise and audit but does not, on its own, create. If your procurement process requires a specific certification, tell us directly rather than assuming either answer.
Where data is held and who can reach it
Contributor and task data is logically partitioned into five regional databases by the contributor's country of residence, each with its own access scope. That partition is enforced in the software, not only documented in a policy. All five currently run on infrastructure physically located in the United States; the partition is a logical and access-control boundary today, not a geographic one, and we say that plainly rather than let a regional label imply otherwise.
Clients never see who did the work
Delivered work reaches you without the contributor's identity or pay rate attached. That separation is structural, enforced by what the delivery pipeline actually reads and writes, not a setting somebody could switch off.
Cross-region transfers use real safeguards
Where data moves between regions, for delivery to you or otherwise, we use standard contractual clauses and equivalent transfer mechanisms rather than moving it with no safeguard in place.
Stored files are reached through short-lived links
Captured and submitted files are not served from a public path. Access goes through a signed link that expires in minutes, generated fresh for the person and the request that needs it.
Payout details are never redisplayed in full
A contributor's saved bank or wallet details are masked everywhere they are shown again, including back to the contributor who saved them. Nobody reads a full account number off this platform after the day it was entered.
Who can do what, and the record of it
Role-based permissions, checked server-side
Every sensitive action, reviewing work, changing a payout rail, reading analytics, is checked against the acting account's role on the server before it runs, not hidden behind a menu the client happens not to show.
Second-factor sign-in for client accounts
Client portal accounts can enrol a time-based authenticator app as a second factor from their own security settings. The secret is stored encrypted, never in a form anyone, including us, can read back directly.
Every mutation writes an audit record
Who did it, what changed, and when, recorded at the point of the action rather than reconstructed afterward from logs that happen to still exist.
Encrypted in transit, encrypted at rest
Every connection to the platform runs over TLS. Data at rest is encrypted by the infrastructure it is stored on, our database and file storage providers, which is their default rather than a setting we had to enable correctly.
Who is actually doing the work
Checks on the workforce, not only on the infrastructure. A secure database answers for nothing if the person submitting work is not who they claim to be.
Identity verification before paid work
A liveness check, not a static photograph, confirms a real person behind an account before it can take on sensitive work, with results reviewed by staff rather than auto-decided silently.
Sanctions and screening checks run continuously
Accounts are checked against sanctions lists on an ongoing basis, not only once at signup, and a match holds the account for a person to review rather than acting on it automatically.
Ask us directly
A security questionnaire, a data processing agreement, or a question this page did not answer: ask directly rather than guess from what is published here.