Access is a decision. Not a side effect.
Giving an external team access to customer data, CRM records, or internal systems is a serious decision. Veilancy treats it as a designed control environment: tailored to each client's workflow, documented in the account playbook, and governed by the practices below.
Every client brings a different stack, sensitivity level, and compliance context. Instead of a generic checklist, we design controls around your specific engagement, your tools, data boundaries, access rules, and reporting expectations.
The practices below are engagement requirements to agree and verify before work begins. They are not evidence of certification, completed staff checks or signed agreements. Application guards have isolated test evidence; production rollout, authenticator enrollment and external controls still require verification. Sensitive file sharing remains blocked while malware scanning is not configured.
Thirteen practices to agree and verify.
- 01
Role-based access
Team members get access to the systems their role requires and nothing beyond it. Requests go through the account lead, not arranged informally.
- 02
Client-controlled permissions
Accounts are provisioned inside your own tools, under your own administration. You decide what each seat can see, and can change or withdraw it anytime.
- 03
Confidentiality agreements
Confidentiality terms covering client, customer and commercial data must be agreed and signed by the relevant parties before access is granted. Client-specific terms are subject to review.
- 04
Credential practices
We favour individually named accounts over shared credentials wherever your tooling supports them. Where credentials must be issued, they're handled by the account lead and recorded for rotation on exit.
- 05
Multi-factor authentication
Require and verify MFA on supported client systems according to the agreed access policy. Enrollment and unsupported tooling must be checked for each engagement; neither is assumed complete.
- 06
Password management
Team members must use a password manager for work credentials, and never store client passwords in personal notes, browsers, or messaging apps.
- 07
Device requirements
Agree a device baseline covering current OS, disk encryption, screen lock and a separate work profile. Verify evidence before granting sensitive access; this page does not attest to any device's compliance.
- 08
Offboarding and access revocation
When someone leaves an account or the company, access revocation is a checklist item with a named owner. The client is notified and can verify removal in their own admin console.
- 09
Escalation procedures
Every engagement has a defined escalation path with named contacts on both sides, so a suspected issue reaches a decision-maker fast.
- 10
Client data boundaries
Teams use client tools or agreed Veilancy workflows. Approved AI and storage processing, access, retention and data locations are defined in the engagement terms. Personal storage and unapproved exports are prohibited.
- 11
Process documentation
Handling rules for each engagement are written into the account playbook, so new team members are trained on them rather than inheriting them by habit.
- 12
Incident response
Agree incident contacts, reporting timeframes and containment responsibilities before launch. Record incidents and communication evidence; response-time execution has not been verified by this page.
- 13
Tooling approval and review
New tools touching client work are approved before use, not adopted quietly. Access lists are reviewed on a set cadence and whenever a role changes.
Checks you can run yourself.
Your admin console is the source of truth
For client tools, verify named accounts in your admin console. For agreed Veilancy workflows, request the scoped access and audit evidence.
Access changes are announced
Agree who communicates account changes and how removal is verified. Keep a dated record rather than assuming same-day execution.
Controls are written before work starts
Access rules, data boundaries, escalation contacts, and reporting cadence are agreed in the account playbook during the pilot, not negotiated after an issue.
Your paper, if you prefer it
We'll work to your NDA, security addendum, or vendor questionnaire, and answer plainly, including where a control isn't in place yet.
If you believe there's a security issue involving Veilancy, our website, or an engagement, email contact@veilancy.com with the details. Reports are reviewed by a named owner, and we'll confirm receipt within one business day.
Have a control
we need to meet?
Send it with your pilot request. We'll tell you plainly what we can support today, what we'd need to put in place, and what we can't do.