This policy governs how Gradio Security LTD manages access to systems, data, and infrastructure. It defines our zero-standing-access model, ephemeral access provisioning, authentication requirements, credential management, audit logging, and data destruction procedures — aligned with UK GDPR, ISO 27001, and SOC 2 controls.
1. Purpose and scope2. Access control principles3. Zero standing access (ZSA) model4. Ephemeral access provisioning5. Authentication and identity6. Authorisation and role-based access (RBAC)7. Credential and secret management8. Session management9. Audit logging and monitoring10. Incident response and breach handling11. Data destruction and secure deletion12. Third-party and sub-processor access13. Client codebase access (audit engagements)14. Physical security15. Roles and responsibilities16. Compliance mapping17. Training and awareness18. Policy review and version history19. Contact us
This Security & Ephemeral Access Policy defines the technical and organisational measures Gradio Safety LTD implements to protect systems, data, and infrastructure from unauthorised access, modification, disclosure, or destruction. It applies to all employees, contractors, sub-processors, and temporary collaborators who interact with our systems or client data.
This policy covers:
Our access control framework is built on the following principles:
| Principle | Description | Implementation |
|---|---|---|
| Least privilege | Users receive only the minimum access required to perform their role — no more, no less | Role-based access control (RBAC) with granular permissions; default deny |
| Zero standing access | No permanent access to production systems. All elevated access is temporary and must be requested | Ephemeral access with automatic expiry (see Section 3) |
| Need-to-know | Access to data is granted only when there is a legitimate business need | Access requests require justification; reviewed by a second person |
| Separation of duties | No single person can complete a sensitive action without oversight | Approval workflows for production changes, deploys, and data access |
| Deny by default | All access is denied unless explicitly granted | Allowlist-based access; no blanket permissions |
| Auditability | Every access event is logged and attributable to an individual | Immutable audit logs with tamper detection (see Section 9) |
| Time-bound | All access has an expiry — no perpetual grants | Automatic revocation after TTL; access must be re-requested |
Gradio Safety LTD operates a zero standing access model. This means that no user — including administrators, engineers, and founders — has permanent, always-on access to production systems, client data, or sensitive infrastructure.
The ZSA model reduces the blast radius of compromised credentials, limits insider threat exposure, and ensures that every access event is intentional, logged, and auditable.
Ephemeral access is temporary, time-bound access to a system or resource that is automatically provisioned on request and automatically revoked when the time-to-live (TTL) expires.
| Step | Action | Details |
|---|---|---|
| 1. Request | User submits an access request via the access management tool | Must include: target resource, justification, duration needed, task description |
| 2. Approval | A second person (manager, peer, or on-call) approves or denies the request | No self-approval. For production access, approval must come from a different team member |
| 3. Provisioning | Access is automatically provisioned with the requested TTL | Credentials are issued dynamically — no static keys are used |
| 4. Usage | User accesses the resource within the granted time window | All actions are logged and attributed to the user |
| 5. Expiry | Access is automatically revoked when the TTL expires | No manual revocation required. Credentials are destroyed |
| 6. Audit | The access event is recorded in the audit log | Includes: who, what, when, justification, approver, duration, actions taken |
| Resource type | Maximum TTL | Approval required | Notes |
|---|---|---|---|
| Production infrastructure (Vercel, Cloudflare admin) | 8 hours | Yes — second team member | Auto-revoke at TTL expiry; no renewal without new request |
| Client codebase (audit engagement) | 4 hours | Yes — engagement manager | Access scoped to read-only unless explicitly approved |
| Client data (architecture diagrams, reports) | 4 hours | Yes — engagement manager | Download disabled; view-only in most cases |
| Payment processor admin | 2 hours | Yes — founder / finance lead | Restricted to authorised personnel only; all actions logged by processor |
| GitHub admin (org settings, secrets) | 8 hours | Yes — second team member | Read access to repos is persistent; admin access is ephemeral |
| Google Workspace admin | 8 hours | Yes — second team member | User management, security settings, audit log access |
| Notion admin | 8 hours | Yes — second team member | Workspace settings, integration management |
| Database / data store | 2 hours | Yes — second team member | Query-level logging enabled; results export blocked |
All access to Gradio Safety LTD systems requires strong authentication. We enforce the following authentication standards:
Access to systems and data is managed through role-based access control. Each role has a defined set of permissions, and users are assigned roles based on their job function.
| Role | Persistent access | Ephemeral access (on request) | Approval authority |
|---|---|---|---|
| Founder / Director | Email, calendar, Notion (read), GitHub (read) | All systems (production, payment, admin) | N/A (but actions are logged and reviewed quarterly) |
| Lead Architect | Email, GitHub (read/write own repos), Notion (read/write) | Production, client codebases, client data | Engagement manager or founder |
| Security & Compliance Lead | Email, GitHub (read), Notion (read/write), audit logs (read) | All systems for security investigations | Founder |
| DevOps & Infrastructure Lead | Email, GitHub (read/write), Vercel (read), Cloudflare (read) | Production infrastructure (write), DNS, SSL | Founder or Lead Architect |
| Data Engineer | Email, GitHub (read), Notion (read) | Databases, data pipelines, analytics tools | Lead Architect or DevOps Lead |
| Engagement Manager | Email, Notion (read/write), payment portal (read) | Payment processor admin, client systems | Founder |
| Contractor / Temporary collaborator | Email (if issued), specific repo access (read) | Scoped to engagement only; maximum TTL 4 hours | Engagement manager or Lead Architect |
All credentials, secrets, API keys, and certificates are managed through approved tools and processes:
| Credential type | Storage | Rotation | Notes |
|---|---|---|---|
| User passwords | Approved password manager (1Password / Bitwarden) | On suspicion of compromise or at least annually | Never stored in browsers, notes, or plain text |
| API tokens (GitHub, Vercel, Cloudflare, etc.) | Secrets manager (GitHub Secrets, Vercel env vars, Cloudflare secrets) | Every 90 days or on personnel changes | Scoped to minimum permissions; no global tokens |
| SSH keys | Ephemeral — issued per session, destroyed on expiry | Per session (no persistent SSH keys) | No SSH keys on production servers; access via ephemeral certificates |
| Database credentials | Secrets manager — never in code or config files | Every 90 days | Connection strings are injected at runtime, not committed |
| Payment processor API keys | Payment processor dashboard (restricted keys) | Every 90 days or on personnel changes | Restricted keys only — no unrestricted keys |
| TLS/SSL certificates | Cloudflare (managed) or Let's Encrypt (auto-renew) | Automatic (90 days for Let's Encrypt, managed by Cloudflare) | No manual certificate management |
| Client-provided credentials | Approved password manager, shared vault scoped to engagement | Returned or destroyed at engagement end | Never reused; access logged |
All access events and administrative actions are logged and monitored. Our logging framework includes:
| Log category | What is logged | Retention | Review frequency |
|---|---|---|---|
| Authentication logs | Login attempts, MFA challenges, SSO events, failed logins, lockouts | 12 months | Weekly (automated alerts for anomalies) |
| Access grants | Ephemeral access requests, approvals, grants, revocations | 24 months | Monthly |
| Administrative actions | Config changes, permission changes, user provisioning/deprovisioning | 24 months | Monthly |
| Data access | Access to client data, database queries, file downloads | 24 months | Monthly + on engagement close |
| Deployment logs | Code deploys, infrastructure changes, DNS changes | 12 months | Per deployment |
| Security events | Failed access attempts, privilege escalation, suspicious activity | 24 months | Real-time alerts + weekly review |
Logs are stored in append-only storage with tamper detection. Access to audit logs requires ephemeral elevated access and is itself logged. Logs are reviewed by the Security & Compliance Lead on a monthly basis and by the founder on a quarterly basis.
If a security incident or suspected breach occurs, the following response process is followed:
| Phase | Action | Timeframe |
|---|---|---|
| 1. Detection | Incident identified via monitoring, alert, or user report | Real-time alerts; user reports within 1 hour |
| 2. Containment | Revoke all access for affected accounts; isolate affected systems | Within 1 hour of detection |
| 3. Assessment | Determine scope: what data, systems, and users are affected | Within 4 hours |
| 4. Notification | Notify affected clients, the ICO (if personal data breach), and relevant authorities | Within 24 hours (ICO: within 72 hours per UK GDPR) |
| 5. Eradication | Remove the root cause: rotate all credentials, patch vulnerabilities, close access paths | Within 24 hours |
| 6. Recovery | Restore systems to normal operation; verify integrity | Within 48 hours |
| 7. Post-incident review | Root cause analysis, lessons learned, policy updates | Within 2 weeks |
All security incidents are documented in an incident register and reviewed by the founder. Material incidents are reported to clients as required by our contracts and to the ICO as required by UK GDPR Article 33.
When data is no longer needed — at the end of an engagement, when a retention period expires, or when a client requests deletion — Gradio Safety LTD securely destroys the data using the following methods:
| Data type | Destruction method | Verification |
|---|---|---|
| Client codebase access | Revoke all credentials, remove SSH keys, close GitHub collaborator access | Confirm no active sessions; verify access removed in GitHub settings |
| Client data (diagrams, reports, audit findings) | Secure delete (shred / srm) from all storage locations; empty trash; clear backups after retention window | Verify files no longer exist in any storage; log destruction in engagement record |
| Client-provided credentials | Remove from password manager; confirm deletion with client | Verify no remaining copies in any vault or system |
| Ephemeral access credentials | Automatic destruction on TTL expiry — credentials are cryptographically erased | Verified by access management tool; logged in audit trail |
| Local copies on laptops/workstations | Secure delete (shred / srm); full-disk wipe if device is decommissioned | Verify with file recovery tool; log destruction |
| Cloud-stored data (Vercel, Cloudflare) | Delete via admin console; verify deletion across all regions and backups | Confirm via API that resources are gone; check backup retention |
| Email and communication records | Per retention policy; secure delete when retention period expires | Verify deletion in email system and backups |
Sub-processors and third-party tools that interact with our systems or data are subject to the following controls:
Current sub-processors and their access scope are listed in our Privacy Policy (Section 8: Sub-processors).
During security audits and architecture reviews, Gradio Safety LTD may need access to client codebases. The following controls apply:
Gradio Safety LTD operates as a remote-first company. There is no central office that stores servers, client data, or sensitive equipment. Physical security controls include:
| Role | Security responsibility |
|---|---|
| Founder / Director | Ultimate accountability for security. Approves security policy. Oversees incident response. Reviews quarterly access reports. |
| Security & Compliance Lead | Day-to-day security operations. Manages access requests, reviews audit logs, conducts security assessments, leads incident response, maintains this policy. |
| DevOps & Infrastructure Lead | Implements technical security controls. Manages infrastructure access, secrets management, deployment security, and monitoring. |
| All staff | Follow this policy. Use approved tools. Report security concerns immediately. Complete security training. Never share credentials. |
This policy maps to the following regulatory frameworks and standards:
| Framework | Relevant controls | Policy sections |
|---|---|---|
| UK GDPR / EU GDPR | Article 32 (security of processing), Article 28 (processor obligations), Article 33 (breach notification) | Sections 2, 3, 4, 7, 9, 10, 11, 12 |
| ISO 27001 / 27002 | A.9 (access control), A.10 (cryptography), A.12 (operations security), A.16 (incident management), A.17 (business continuity) | Sections 2–11, 14, 15 |
| SOC 2 (Trust Services Criteria) | CC6 (logical and physical access), CC7 (system operations), CC8 (change management), CC9 (risk mitigation) | Sections 2–9, 12–15 |
| PCI DSS | Requirement 7 (restrict access), Requirement 8 (identify users), Requirement 10 (monitor access), Requirement 12 (security policy) | Sections 2–9, 15 |
| NIST SP 800-88 | Media sanitisation guidelines | Section 11, 14 |
| NIST SP 800-63B | Digital identity guidelines — authentication | Section 5 |
All staff receive security awareness training as part of their induction and annual refresher training. The training covers:
Training completion is recorded and retained for 5 years. The Security & Compliance Lead reviews and updates the training content annually.
This policy is reviewed every 6 months by the Security & Compliance Lead and approved by the founder. It is updated whenever:
v2.0 2026-08-28 Full rewrite — 19 sections: ZSA model, ephemeral access workflow, TTL matrix, MFA/SSO, RBAC table, credential management, session management, audit logging, incident response, data destruction, third-party access, client codebase access, physical security, compliance mapping, trainingv1.0 2026-08-27 Initial placeholder
For questions about this Security & Ephemeral Access Policy, to report a security concern, or to request additional information: