How we work inside your systems.
Our work touches email, DNS and websites — the parts of a business that cannot afford to be handled loosely. This page sets out, without ambiguity, who you are contracting with, how we handle access and credentials, and what we commit to if something goes wrong.
Who you are dealing with
One legal entity provides the service, receives payment, is responsible for your data and is liable under the contract. There is no chain to untangle.
| Service provider | Yeevu LLC, operating under the YeevuFix brand. YeevuFix is not a separate company. |
|---|---|
| Contracting party | Yeevu LLC, a limited liability company. |
| Responsible for your data | Yeevu LLC is the data controller for the information you share with us about you and your business, and acts on your instructions when handling data inside your own systems. See our Privacy Policy. |
| Liable under the contract | Yeevu LLC, on the terms and within the limits set out in our Terms of Service. |
Our access model
We use temporary, least-privilege access wherever the platform allows it, we strongly advise multi-factor authentication on every account we touch, and we always recommend changing credentials once the work is complete.
- 01
A named account, not your login
Where the platform supports it, you create a user or delegated access specifically for us. We do not work from your primary owner login, and we do not share accounts between engagements. Where a platform offers no delegated access, we will need to sign in with your credentials to carry out the work; in that case you provide temporary login details for the duration of the engagement, and we ask you to change the password as soon as the work is complete.
- 02
Least privilege by default
We ask only for the roles the work requires — a DNS editor rather than an account owner, a site administrator rather than a hosting-account holder. If a task needs more, we say so and explain why before proceeding.
- 03
Multi-factor authentication
We require MFA on any account we are granted. If it is not yet enabled, enabling it is the first thing we ask of you, and we will walk you through it.
- 04
Access is time-boxed to the engagement
Access is granted for the work in hand and ends when the work ends. Ongoing access exists only under a maintenance arrangement you have agreed to in writing.
- 05
Documented revocation at close
Every engagement finishes with a written revocation checklist so you can remove our access with certainty. It is set out in full below.
Security practices
The controls we apply on every engagement, stated as we actually operate them.
Credential handling
Credentials are held only in an encrypted password manager — never in chat threads, email, documents or screenshots. Anything sent to us over an insecure channel, we ask you to rotate.
No retention after close
We do not keep your credentials once the engagement ends. Any access tokens, API keys or app passwords issued to us should be revoked on your side; we confirm from ours that nothing is retained.
Prior state captured before every change
Before any DNS, email or website change we capture the existing state — a record export, a configuration snapshot or a site backup — so the change can be reverted precisely if needed.
Backup and restore responsibilities
We restore what we changed. Your own backup regime continues to cover everything outside the scope of our work, and we will tell you if we think that regime needs attention.
Incident notification
If we cause or discover a security incident affecting your systems or data, we notify you within 24 hours of becoming aware of it, with what we know and what we recommend.
Data retention and deletion
Working data from an engagement — exports, screenshots, reports, diagnostic output — is retained for no more than 90 days after close and then deleted, unless you ask us to keep it.
Our own systems
Every internal account is protected by multi-factor authentication and the devices we work from are disk-encrypted. Client work is separated per engagement.
Confidentiality
What we learn about your business, your systems and your customers in the course of an engagement stays confidential, during the engagement and after it. This obligation is written into our Terms of Service.
Revoking our access
The checklist we send at the close of every engagement. You may request it at any point during the work as well.
- Remove the user, delegate or collaborator access created for us on each platform — registrar, DNS provider, hosting control panel, email administration and any CMS.
- Revoke any API key, access token, application password or OAuth grant issued to us during the work.
- Rotate any credential that was shared with us directly rather than created for us, and any credential sent over an insecure channel.
- Confirm MFA remains enabled on every account we touched, and that no recovery method has been added that you do not recognize.
- Review the change log we deliver with the work so you know exactly what was altered and can verify it independently.
- Reply to confirm revocation is complete. We confirm in return that we hold no credentials and that working data will be deleted within 90 days.
Written into the contract, not just this page
Confidentiality, data protection, our security obligations, breach notification, our responsibility for mistakes and how we put them right, response commitments and the limits of liability are all set out in our Terms of Service. If your organization needs any of this in a signed form, or has questions before granting access, get in touch.
Read the Terms of Service Get in touch