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.
Security & Data Practices
Client access should be limited, deliberate, and easy to hand back.
KGS may need access to business systems, configurations, data, or vendor information to do the work. The default is to ask for the least access needed, keep client control wherever practical, and agree on requirements for the specific project 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.
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
Share enough to explain the need, not sensitive data.
Information submitted through the contact form is used to evaluate the inquiry and respond. The form includes basic safeguards against abuse, but 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 noticeAI 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.
Bring security requirements into the scope before access is granted.
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.
Have security or data handling requirements KGS should know about?
Include them with the initial inquiry or raise them before access is discussed.