Security & Data Practices

Agree the access and information the work needs.

KGS may need access to business systems, settings, data or vendor information. The default is to ask for the least access needed and keep control with the client wherever practical. Project requirements are agreed before access is granted.

This page describes KGS operating practices. It is not a security certification, legal compliance determination, penetration test, or guarantee. Requirements for a specific engagement belong in the proposal and agreement.

How access and project information are handled.

Use only the access needed

Access should match the agreed scope. KGS prefers the lowest level of access that can do the job and removes, reduces, or transfers access when it is no longer needed.

Keep control with the client

Accounts, credentials, configurations, code, and records should remain under client ownership or be readily transferable whenever practical.

Keep passwords and keys out of email

Passwords, API keys, tokens, and other secrets should be shared through an approved password manager or secure transfer method, not ordinary email or project notes.

Use less data when less will do

KGS asks for the smallest useful set of information. Redacted records, samples, screenshots, or configuration views may be enough without collecting a broader production data set.

Be clear about outside services

When an outside platform or specialist is materially involved in the work, its role should be clear before sensitive information or production access is involved.

Close out access and document the handoff

Before an engagement closes, applicable access, ownership, operating instructions, remaining risks, and transition steps should be recorded.

Website inquiries

Use the inquiry form to describe the problem.

KGS uses contact-form information to evaluate the inquiry and respond. The form has basic safeguards against abuse. It is not intended for confidential records or production credentials.

Do not send passwords, API keys, payment card information, health information, government identifiers, regulated records, or sensitive client data through the form or ordinary email.

If an engagement requires sensitive information, KGS will agree on an appropriate transfer method after contact is established.

Read the website privacy notice
AI use

AI use is discussed before client data is sent to an AI provider.

When AI is material to an engagement, the provider, purpose, and data involved should be clear enough for the client to make an informed decision. Important outputs need an accountable reviewer, an override path, and a fallback when the tool is unavailable or wrong.

Identify the AI provider or model that is material to the workflow.

Agree on what client information may be sent and what should be excluded or redacted.

Review relevant retention and training settings before production use when they matter to the data involved.

Define who reviews, approves, or can override important outputs.

Keep a fallback for work that cannot safely depend on a model being available or correct.

Do not reuse client data to train a KGS model or unrelated system without explicit written authorization.

Raise security requirements before granting access.

KGS can document the systems in scope, proposed access, relevant service providers, data categories, storage expectations, incident contacts, handoff plan, and material limitations for the work.

Formal security questionnaires, terms for data processing, cyber insurance requirements, background checks, tools required by the client, or other controls may affect scope, timing, and price. Those requirements should be raised early.

What security or data requirements does your project have?

Include them with the initial inquiry or raise them before access is discussed.

Talk to KGS