Not in project documentation
Passwords should not be stored in ordinary project documentation, tickets, chat threads or shared notes, where they outlive their purpose and spread beyond the people who needed them.
KRUQ Trust Center 2026
Trust is built
into delivery.
A practical overview of how KRUQ approaches security, privacy, access management, responsible AI and operational control throughout technology projects.
-
Least privilege
Access is limited to what a project requires.
-
Data minimisation
Only information necessary for delivery should be requested.
-
Controlled delivery
Changes are versioned, tested and released deliberately.
-
Human oversight
AI-assisted work remains subject to human review.
Security
Access and change are the two places where most risk enters a project. Both are handled deliberately, from the first credential request through to production release.
-
Least-privilege access
Permissions are requested against a defined task rather than as broad administrative access. Where a narrower role achieves the same outcome, the narrower role is used.
-
Named accounts where supported
Individual named accounts are preferred over shared logins so that activity remains attributable within the client's own systems and audit trails.
-
Access removal when no longer required
Access granted for a specific phase is intended to be withdrawn once that phase ends, and remaining access is reviewed as the engagement closes.
-
Version control
Work is tracked in version control so that changes have history, authorship and a reviewable record rather than arriving as untracked edits.
-
Testing before production release
Changes are exercised in a non-production context appropriate to the project before they are proposed for a production environment.
-
Controlled deployments
Releases are planned, scheduled and reversible where the platform allows, rather than applied ad hoc to live systems.
Credentials & Secrets
Credentials are treated as sensitive material with their own handling rules, separate from ordinary project documentation.
Not committed to repositories
Secrets should not be committed to source-code repositories. Repository history is long-lived and widely readable, so a committed secret should be treated as disclosed even after removal.
Appropriate secret management
Where the platform or client environment offers secret management — a vault, a managed secret store or environment-level configuration — those methods should be used in preference to manual handling.
Rotation on suspected exposure
If exposure is suspected, the credential should be rotated rather than assessed for likelihood of misuse. Rotation is treated as the ordinary, low-drama response.
Privacy & Data Handling
The safest data is the data a project never needed to hold. Handling starts by narrowing what is requested in the first place.
Purpose limitation
Data accessed during an engagement is used for the delivery purpose it was provided for, and not repurposed for unrelated activity.
Minimum necessary access
Access is scoped to the systems and records a task genuinely requires, rather than to whatever the client's role model makes convenient to grant.
Data minimisation
Where a task can be completed with anonymised, masked, sampled or synthetic data, that is preferred to working against a full production dataset.
Client-controlled production environments
Where appropriate, production environments and the data inside them remain under the client's own control and administration, with KRUQ working through the access the client grants.
Review of remaining access at closure
Project closure includes reviewing what access, accounts and copies of data still exist, so that nothing quietly persists past the end of the work.
Third-Party Services
Modern software is assembled as much as it is written. What a solution depends on is part of the solution.
APIs, cloud services, libraries and external platforms are treated as explicit project dependencies rather than invisible implementation detail. Their role, and the implications of relying on them, should be considered during solution design — while the choice is still open — instead of being discovered after a system is already built around them.
Responsible AI
AI is used as an engineering tool inside a controlled process — not as an unreviewed author of client deliverables.
Human Review
AI-assisted work is reviewed before becoming a client deliverable or production change. A person remains accountable for what is handed over.
Confidentiality First
Confidential client information should not be submitted to AI systems without appropriate authorisation and safeguards. Where in doubt, the default is not to submit it.
Fit for Purpose
AI should be used where it creates genuine project value and should not blindly replace human judgement. The measure is the quality of the outcome, not the novelty of the method.
Delivery Controls
Each stage has its own entry point, its own controls and its own exit. Access and change are granted stage by stage, not all at once.
-
Discovery
Scope, constraints, environments and data sensitivity are established, along with what access the work will actually require.
-
Access
Least-privilege access is requested against that scope, using named accounts where supported and the client's own approval process.
-
Build
Work proceeds under version control with review, in non-production environments, with secrets kept out of the repository.
-
Release
Changes are tested, then deployed deliberately — planned, agreed with the client and reversible where the platform allows.
-
Handover
Documentation, ownership and credentials transfer to the client, and access that is no longer required is reviewed and removed.
Project Governance
Governance is what keeps a project legible: what was agreed, what changed, and how anyone can tell whether it is on track.
Statement of Work
Scope, deliverables, assumptions and responsibilities are written down before delivery begins, so both sides are working from the same document.
Scope control
Work is delivered against the agreed scope. Items outside it are identified as such rather than absorbed silently into the schedule.
Change requests
Changes to scope, approach or timeline are raised explicitly, with their impact on effort and delivery made visible before they are accepted.
Acceptance criteria
Deliverables are defined so that "done" is verifiable — a shared, stated standard rather than a matter of impression.
Status and risk visibility
Progress, blockers and risks are reported during the engagement, while there is still time to act on them.
Structured handover
Closure is a defined step: documentation, ownership, credentials and access are transferred and reviewed rather than left to lapse.
Position
Transparency over claims
KRUQ believes trust should be based on clear practices and verifiable commitments rather than unsupported marketing claims.
Security & Trust
Need project-specific assurance?
For vendor onboarding, due diligence or project-specific security requirements, contact KRUQ. Requirements can be reviewed during discovery and documented in the applicable proposal, Statement of Work or security annex.