Security and incident response

Grydor is a high-privilege device-management system. Security claims are tied to observable controls and do not treat a successful network request as proof that a device action completed.

Security controls

• PostgreSQL Row-Level Security and transaction-scoped tenant context protect business data across API and worker paths.
• Administrator roles, fresh authentication, explicit reasons, and immutable audit evidence protect sensitive operations.
• Agent requests are device-signed and bind tenant, device, key, body, timestamp, and nonce. Apple and Windows MDM use separate platform identities and protocol validation.
• Secrets and private keys are encrypted or stored in platform secret stores. Logs exclude tokens, recovery keys, SCEP challenges, private keys, script secrets, and unrestricted protocol payloads.
• Workers use leases, deadlines, idempotency, and bounded retry. Device wake acceptance remains separate from device session and command completion.
• Release artifacts require digest, signature, target architecture, provenance, and rollback evidence. Dependencies and bundled native binaries are pinned and reviewed.
• Backups, restore tests, monitoring, rate limits, parser budgets, fuzzing, and production canaries are part of the release process.

These controls do not represent a certification. Grydor will identify completed external attestations by name, scope, auditor, and period instead of implying SOC 2 or ISO 27001 coverage before it exists.

Report a vulnerability

Send a private report to [email protected] with the affected surface, reproducible steps, impact, and a safe contact method. Do not access another customer’s data, degrade service, use social engineering, persist after proving impact, or publish secrets. Grydor does not currently operate a public bug-bounty program and cannot promise payment without a written agreement.

We acknowledge valid reports, assign severity, preserve evidence, contain exposure, develop and verify a fix, deploy according to risk, and communicate remediation. Good-faith research that respects these boundaries will not be referred for legal action by Grydor solely because it bypassed a technical control to demonstrate the reported issue, subject to applicable law and third-party rights.

Customer incident process

1. The on-call responder records the report, time, reporter, affected systems, and initial evidence.
2. The incident lead limits further loss, protects forensic evidence, rotates or revokes affected credentials, and engages engineering, privacy, legal, operations, and communications roles as appropriate.
3. The team determines tenant scope, data categories, time window, exploit path, persistence, and whether Customer Personal Data was affected.
4. Affected customers receive notice without undue delay after a Personal Data Breach is confirmed. Initial facts may be incomplete; updates identify what changed.
5. Remediation is verified through tests, monitoring, credential review, recovery checks, and a documented decision to restore normal operation.
6. A post-incident review records root cause, customer impact, corrective actions, owners, deadlines, and evidence of completion.

Customer notices describe known facts, affected information and systems, likely consequences, containment, actions the customer should take, and a contact point. Grydor does not delay a required notice merely to finish a root-cause analysis, and it does not make misleading claims about certainty.

Availability and support events

An operational outage is not automatically a Personal Data Breach. Grydor still communicates material service degradation through the contracted support channel and a public service notice when appropriate. Security-sensitive details may be withheld while disclosure would increase risk, but affected customers receive enough information to take protective action.

Contact

• Security reports: [email protected]
• Privacy and DPA questions: [email protected]
• Contract and support contacts: the addresses stated in the applicable Order Form