Security

How we handle access and customer data

Security work can require sensitive context. We agree what we need, use the narrowest practical access, and document how evidence will be handled before an engagement starts.

Scope before access

Accounts, repositories, environments and exclusions are agreed in writing before we begin technical work.

Least privilege

Read-only or time-bound roles are preferred. Write access is limited to the changes the customer has authorised.

Minimum evidence

We collect only what supports the agreed finding or control and avoid copying secrets or production data into reports.

Clear closure

At the end of the work, temporary access is removed and retained deliverables follow the agreed handover and deletion plan.

Before an engagement

The working rules depend on the system and the job. The statement of work or rules of engagement should identify:

  • In-scope organizations, accounts, subscriptions, projects, repositories and applications
  • Approved identities, access level, test window and customer contacts
  • Systems or actions that are explicitly out of scope
  • How critical findings and suspected incidents will be escalated
  • Where working evidence and final deliverables may be stored

Access to customer systems

We ask for access that matches the task rather than broad permanent administrator accounts.

  • Customer-managed, named identities are preferred over shared credentials
  • Read-only access is used for assessments unless implementation is part of the scope
  • Production changes follow the customer's review and change process
  • Secrets should remain in the customer's approved secret-management system
  • Temporary roles and test accounts should be revoked when the work ends

Evidence and reports

Reports need enough detail to reproduce a finding without becoming a new source of risk.

  • Screenshots and exports are limited to fields relevant to the issue or control
  • Passwords, tokens, private keys and unnecessary personal data are excluded
  • Critical findings are communicated through an agreed private channel
  • Retention or deletion requirements can be added to the engagement terms

Compliance boundaries

Gritt provides technical assessments, control implementation, readiness and remediation. We do not imply that a readiness engagement is a certification or independent audit. A SOC 2 examination is performed by an independent licensed CPA firm; other regulated or certified work may also require a specifically qualified assessor.

If your buyer requires a named accreditation, empanelment, testing standard, data location or contractual control, include it before scope so we can confirm whether Gritt is the right provider.

Vulnerability Disclosure

If you believe you have found a vulnerability in gritt.cloud, please:

  • Email the address below with a concise description
  • Include steps to reproduce the issue
  • Allow reasonable time for investigation and remediation
  • Do not access or modify customer data
  • Do not perform denial-of-service or social-engineering tests

Security contact

For an engagement-security question or a responsible disclosure, email . Existing customers should also use the contact and escalation route in their engagement documentation.