HelpWithEmails

Trust & Security

HelpWithEmails works inside business email, DNS and marketing platforms, the systems a business cannot afford to have handled loosely. This page sets out who the contract is with, how access and credentials are handled, and what happens if something goes wrong.

Who Clients Contract With

One legal entity provides the service, receives payment, is responsible for client data and is liable under the contract.

Service provider
Yeevu LLC, trading as HelpWithEmails. HelpWithEmails is a brand of Yeevu LLC, not a separate company.
Contracting party
Yeevu LLC, a limited liability company registered in Wyoming, USA.
Responsible for data
Yeevu LLC is the data controller for the information clients share about themselves and their business, and acts on the client's instructions when handling data inside the client's own systems. See the Privacy Policy.
Liable under the contract
Yeevu LLC, on the terms and within the limits set out in the Terms of Service.

HelpWithEmails Access Model

Access is temporary and limited to what the work needs wherever the platform allows it. Multi-factor authentication is required on every account granted, and credentials should be changed once the work is complete.

  • A named account, not the owner login. Where the platform supports it, the client creates a user or delegated access specifically for HelpWithEmails. Work never runs from the client's primary owner login, and accounts are never shared between engagements. Where a platform offers no delegated access, the client provides temporary login details for the engagement and changes the password as soon as the work is complete.
  • Least privilege by default. Only the roles the work requires are requested: a DNS editor rather than an account owner, a mailbox administrator rather than a billing owner. If a task needs more, that is explained before anything proceeds.
  • Multi-factor authentication. MFA is required on any account granted. If it is not yet enabled, enabling it is the first step, with help to set it up.
  • Access limited to the engagement. Access is granted for the work in hand and ends when the work ends. Ongoing access exists only under a monitoring or maintenance arrangement agreed in writing.
  • Documented revocation at close. Every engagement finishes with a written revocation checklist, set out in full below.

HelpWithEmails Security Practices

The controls applied on every engagement, stated as they actually operate.

  • Credential handling. Credentials are held only in an encrypted password manager, never in chat threads, email, documents or screenshots. Anything sent over an insecure channel should be rotated.
  • No retention after close. Credentials are not kept once the engagement ends. Any access tokens, API keys or app passwords issued for the work should be revoked on the client's side.
  • Prior state captured before every change. Before any DNS, email or platform change, the existing state is captured, such as a record export or a configuration snapshot, so the change can be reverted precisely.
  • Backup and restore responsibilities. HelpWithEmails restores what it changed. The client's own backups continue to cover everything outside the scope of the work.
  • Incident notification. If HelpWithEmails causes or discovers a security incident affecting a client's systems or data, the client is told within 24 hours, with what is known and what is recommended.
  • Data retention and deletion. Working data from an engagement, such as exports, screenshots, reports and test output, is kept for no more than 90 days after close and then deleted, unless the client asks for it to be kept.
  • Internal systems. Every internal account is protected by multi-factor authentication, work devices are disk-encrypted, and client work is kept separate per engagement.
  • Confidentiality. What is learned about a client's business, systems and customers stays confidential during the engagement and after it, as written into the Terms of Service.

Revoking HelpWithEmails Access

The checklist sent at the close of every engagement. It can be requested at any point during the work as well.

  1. Remove the access created for the work on each platform: registrar, DNS provider, email administration, security gateway and any marketing platform.
  2. Revoke keys and tokens. Remove any API key, access token, app password or OAuth grant issued during the work.
  3. Rotate shared credentials. Change any password that was shared directly rather than created for the work, and any sent over an insecure channel.
  4. Check MFA and recovery. Confirm MFA is still enabled on every account touched, and that no unrecognized recovery method has been added.
  5. Review the change log. The change log delivered with the work lists exactly what was altered, so it can be verified independently.
  6. Confirm completion. Reply to confirm revocation is done. HelpWithEmails confirms in return that no credentials are held and that working data will be deleted within 90 days.

Trust and Security Commitments in the Contract

Confidentiality, data protection, security obligations, breach notification, how mistakes are put right, response commitments and the limits of liability are all set out in the Terms of Service. Organizations that need any of this in signed form, or have questions before granting access, can get in touch.