Compliance
schema. What do you hold about a person? On what basis? From what age? For
how long? Where? Who can read it, and can you prove who did? Those questions
have answers a model can carry — and once it carries them, the ORM can check
the answers against the law, enforce the ones that depend on the row, and
print the whole thing as a sheet.
them:
| Layer | The question |
|---|---|
| Declare | What is this data, and whose rules apply? |
| Enforce | Encrypt it, hide it, gate it, keep it only so long, keep it here. |
| Prove | Show an auditor. |
@Jurisdiction, @Personal and the age gate, checked when the class loads.@Security switches on the controls GDPR, HIPAA, PCI DSS or SOC 2 expect.prorm audit: code rules, database probes, checklist statuses, SARIF.what is enforced rather than what someone remembers.
prorm audit looks at thecode from outside and writes what it finds to a bundle.
every module, whether it is production-grade, a scaffold you finish, or a
simulation. Read it before you rely on anything here in a regulated
environment. This library will not make you compliant; it makes the
schema-shaped part of compliance declarative, checkable and enforceable, and
tells you plainly where its controls stop.
Two ways in
@Jurisdiction. You name the regimes a modelis held to and declare what each personal field is. The class refuses to load
if the declaration breaks the strictest of those regimes; rows are gated by
age at write time; retention ceilings register themselves; the sheet is one
call away.
import { Jurisdiction, Personal, DataSubjectAge, ParentalConsent, Table, Column, DataTypes, Model } from 'ts-prorm-orm';
@Jurisdiction('EU', 'US-CA')
@Table({ tableName: 'patients' })
class Patient extends Model {
@Personal('identifier', { basis: 'contract', subject: true })
@Column(DataTypes.STRING) declare name: string;
@Personal('health', { basis: 'consent', purpose: 'treatment', retention: 'P5Y' })
@Column(DataTypes.TEXT) declare notes: string;
@DataSubjectAge() @Column(DataTypes.DATEONLY) declare birthday: string;
@ParentalConsent() @Column(DataTypes.BOOLEAN) declare guardianConsented: boolean;
}@Security. You name the standards(GDPR, HIPAA, PCI DSS, SOC 2 — 61 of them) and the decorator switches on the
controls each requires: audit, encryption, masking, retention, row-level
security, lineage and so on.
import { Security, SecurityFramework, setupSecurity } from 'ts-prorm-orm';
@Security({
frameworks: [SecurityFramework.GDPR, SecurityFramework.HIPAA],
encrypt: ['ssn'],
mask: { ssn: 'ssn' },
retention: { years: 7 },
})
class Patient extends Model { /* … */ }
setupSecurity(Patient, prorm); // wires the deferred hooks@Jurisdiction('EU') and @Security({
frameworks: [GDPR] }) is told what it may hold and has the controls GDPRexpects switched on. Neither needs decorators —
applyCompliance()and the individual modules take a plain model too.
What is in the module
src/compliance is a set of narrow, single-purpose pieces built on the ORM'sown hooks and decorators. Grouped by what they are for:
| Area | Pieces |
|---|---|
| Jurisdictions | JURISDICTIONS, jurisdiction(), resolve(), @Jurisdiction, @Personal, @DataSubjectAge, @ParentalConsent, applyCompliance(), complianceSheet(), renderComplianceSheet() |
| Frameworks | @Security, @Table, @Database, setupSecurity(), setupAllSecurity(), SecurityFramework, FrameworkRequirements |
| Classification & discovery | DataClassifier (@Classify, @FieldClassification), SensitiveDataDiscovery |
| Protection | FieldEncryption, DataMasker, PseudonymizationService, RowLevelSecurity, SessionIsolation, TLSEnforcer, QueryFirewall, RateLimiter |
| Subject rights | DSARWorkflow, RightToErasure, DataPortabilityExporter, ConsentRecord, ConsentVersioning, PrivacyImpactAssessment |
| Lifecycle & integrity | DataRetentionPolicy, ImmutableRecord, WORMStorage, ComplianceAuditTrail, DataLineage, BackupVerification, BreachDetector, SecurityMonitor |
| Residency | CrossBorderLog, the residency rules inside every jurisdiction |
Where the database does it better
GRANTs, TLS, column encryption at rest — prefer it. A database-enforced ruleholds for every client that ever connects; an application-enforced rule holds
only for code that goes through this ORM. The pages below say, for each
control, which side of that line it is on. See Schema objects → row-level
security and
User management for the database-side tools.
Not legal advice
AS_OF tells you themonth). Laws change, regulators tighten numbers, and a court can read a
statute differently from its text. Every entry names its source; a
jurisdiction you rely on is one to verify against that source, and the
decision about whether a given processing is lawful is a decision for a person
who is accountable for it, not for a decorator.
Modified at 2026-10-04 00:40:16