Arslan Rehmani
Security • What I Can Show You

Security, Permissions & Disaster Recovery.

I build systems for companies whose data must reconcile to the cent and withstand employee churn, hardware failure, and hostile actors. Below is the exact test matrix, access policy architecture, and disaster drill schedule I enforce.

01. Sanitized Permission Test Matrix

Automated CI/CD RLS Assertions

Evaluated across four distinct user states. Permissions are enforced by the database kernel, never purely in frontend JavaScript.

Action / SQL OperationAnonymousInactive StaffActive Floor StaffOwner / Finance
SELECT from public marketing routes ALLOW ALLOW ALLOW ALLOW
SELECT from inventory_lots & yarn_cost DENY DENY ALLOW ALLOW
INSERT into shift_production_entries DENY DENY ALLOW ALLOW
APPROVE supplier invoice / ledger journal DENY DENY DENY ALLOW
SELECT from system_audit_logs DENY DENY DENY ALLOW
ALTER TABLE or mutate RLS policies DENY DENY DENY DENY
02. Disaster Recovery & Restore Verification
Drill Passed

Unrehearsed backups are not backups.

Most companies discover their backup was corrupted only after their primary database fails. Under my Care Plan, automated restore drills pull raw backup dumps into an ephemeral Docker container and execute checksum reconciliation against historical ledger balances.

Date of Last Restore Drill:
October 2026 (Verified sandbox checksum match to the cent)
100% Checksum Equality

03. Real PostgreSQL Row-Level Security Policy

Here is an exact sanitized policy from a production textile ERP. Security is enforced directly in SQL:

-- Enforce strict tenant isolation & shift supervisor insert rights
ALTER TABLE greige_production_runs ENABLE ROW LEVEL SECURITY;

-- 1. Inactive employees have zero access regardless of role
CREATE POLICY "deny_inactive_users"
ON greige_production_runs
AS RESTRICTIVE
TO authenticated
USING (
  (SELECT status FROM auth_profiles WHERE id = auth.uid()) = 'active'
);

-- 2. Shift supervisors can only insert and read data for their assigned shift
CREATE POLICY "supervisors_active_shift_only"
ON greige_production_runs
FOR INSERT
TO authenticated
WITH CHECK (
  auth.jwt() ->> 'role' = 'shift_supervisor'
  AND shift_id = (SELECT current_active_shift FROM factory_state LIMIT 1)
  AND logged_by = auth.uid()
);

-- 3. Only the finance director can approve and close the ledger
CREATE POLICY "finance_director_close_ledger"
ON gl_accounting_closures
FOR ALL
TO authenticated
USING (
  auth.jwt() ->> 'role' = 'finance_director'
  AND (SELECT two_factor_verified FROM auth_profiles WHERE id = auth.uid()) = true
);

04. Cryptographic Audit Log Format

Every sensitive table write logs who executed the change, from what role, with a SHA-256 before/after state hash:

INSERT•greige_loom_runs(run_loom22_shift1)
Actor: usr_shift_supv_04 [shift_supervisor] • 2026-10-24 07:14:02 UTC
VERIFIED
sha256:7e21a...4f18c
INSERT_STAGING•staging_supplier_proposals(stg_inv_8849)
Actor: agent_invoice_parser [staging_service_account] • 2026-10-24 07:18:45 UTC
PASSED_DETERMINISTIC_GATE
sha256:91df4...228ba
RECONCILE_BATCH•gl_reconciliation_batches(batch_20261024)
Actor: usr_acct_lead [finance_manager] • 2026-10-24 07:45:11 UTC
COMMITTED
sha256:3a44b...990ef
SELECT_ATTEMPT•inventory_lots(N/A)
Actor: anon_ip_194.26.29.11 [anonymous] • 2026-10-24 08:02:19 UTC
BLOCKED_BY_RLS
sha256:blocked

05. What You Own (Zero Hostage Policy)

I have zero interest in holding your software hostage. On final deployment, you possess 100% ownership:

Source Code

Clean, typed TypeScript and SQL repository transferred directly to your organization GitHub or GitLab. No proprietary closed dependencies.

Cloud Accounts

Supabase, AWS, and Vercel infrastructure is provisioned inside your commercial accounts. Arslan accesses environments exclusively via scoped IAM developer keys.

Master Encryption Keys

Root database passwords and API encryption keys are generated directly into your password manager. I retain zero backdoor or superuser tokens.

Data Processing Agreement (DPA) Available on Request

Standard Data Processing Agreements compliant with UK GDPR, EU GDPR, and US commercial privacy standards are executed with all build and care clients.

Request DPA template
07. Plain Disclosures: What I Do NOT Do

I build reliable, audited, and defensively programmed operational software. But credibility requires naming exact boundaries:

  • No penetration testing: I do not offer formal adversarial pen-testing. If you require black-box ethical hacking, I will connect you with a CREST-accredited specialist firm.
  • No formal compliance certifications: I build software with SOC2 and ISO-ready access architecture, but I am not an accredited certification auditor and do not issue compliance seals.
  • No speculative financial forecasting: My systems reconcile historical reality to the cent; they do not generate speculative probabilistic financial advice.

Need your operational data secured to this standard?

Book a 20-minute discovery call to review your current permissions and risks.

Book a 20-minute discovery call