Operational information connected to the agreed problem.
- Revenue, project and delivery information
- Financial reporting and commercial records
- Customer or account records where required
- Workflows, dashboards and internal documentation
Trust + Information Handling
Client access deserves operating discipline.
Struktekale works inside the systems, information and workflows that help businesses run. We treat access to those environments as a responsibility—not simply a technical requirement.
01 · AccessOnly what is necessary.
02 · ControlKeep permissions deliberate.
03 · MinimizeAvoid unnecessary data movement.
04 · RemoveClose access when work ends.
Built for work inside real operating systems.
Depending on the engagement, Struktekale may work with project information, revenue data, financial reporting, customer or account records, internal documentation, dashboards, workflows and business systems.
The objective is not to collect everything. It is to use the minimum access and information reasonably necessary to diagnose, design, implement or monitor the agreed work.
Access follows the work—not convenience.
Administrative permissions are requested only when the work reasonably requires them. Where read-only access is sufficient, read-only access is preferred.
- Minimum necessary access
- Clear purpose and ownership
- Client-controlled accounts where practical
- Removal when access is no longer required
Access is designed as a control layer.
Where supported by the client’s systems, we prefer individual accounts, role-based permissions, least-privilege access, multi-factor authentication and clearly documented ownership.
Individual access
Named user accounts are preferred over shared credentials so access can be attributed and removed cleanly.
Client-owned accounts and workspaces remain the preferred operating model where practical.
Least privilege
Permissions should reflect the actual work being performed. Read-only access is used where it is enough.
Administrative access is not the default.
Secure exchange
Passwords should not be sent through ordinary email, chat messages or shared documents.
Established password-management methods are preferred when credentials must be exchanged.
Account security
Accounts used by Struktekale for client work are expected to use strong, unique credentials.
Multi-factor authentication is used where supported.
Client Access Inventory
For engagements involving several systems, Struktekale may maintain a record showing what access exists, why it exists and when it should be removed.System → Account → Access level → Purpose → Owner → Date granted → Date removed
Minimize the data. Control the toolset.
Operational problems rarely require unrestricted access to every record in a business. Data handling and tool selection should be proportionate to the work being performed.
Use what the diagnosis or build actually requires.
Where practical, we avoid unnecessary copies of production data. Aggregated, anonymized, redacted, sample or limited datasets may be used when complete underlying records are not required.
Information should not move between systems merely because it is convenient to do so.
Agree the environment before sensitive information moves.
Struktekale may use established third-party providers to support delivery. When a client has procurement, privacy, security or vendor requirements, the approved toolset can be agreed before sensitive information is introduced.
- Cloud productivity
- Project management
- Documentation
- Analytics + reporting
- Automation
- Communications
- Credential management
- File storage
AI-Assisted Workflows
AI use should be deliberate—not casual.
Struktekale may use AI-assisted tools for research, analysis, workflow design, documentation, automation or operational support. Client confidential information should not be placed into unapproved AI systems simply for convenience.
Before information enters an AI-assisted workflowControl Check
Confirm the approved tool and purpose.
Identify what the system is being used for and whether it is appropriate for the information involved.
Limit the information shared.
Minimize, redact, anonymize, aggregate or separate identifying business information where practical.
Apply client-specific restrictions.
Requirements covering approved vendors, AI use, data residency or information handling should be communicated before relevant information is shared.
Control the full access lifecycle.
Good information handling does not end when delivery ends. Retention and offboarding are part of the engagement—not cleanup tasks to be left undefined.
01 · RetentionKeep only with reason
Client information should not be retained indefinitely.
Information may be retained where reasonably necessary for delivery, quality assurance, documentation, support, contract administration, accounting, recordkeeping or legal obligations.
- Delete or remove from active working environments
- Return or transfer information to the client
- Archive only where there is a legitimate reason
Sensitive or higher-access engagements may use a Data Retention & Deletion Log.
02 · OffboardingClose access deliberately
Access removal is part of completing the engagement.
The required steps depend on the systems and continuing support arrangement.
- Remove Struktekale user accounts and permissions
- Revoke credentials, API keys, tokens and integrations
- Transfer ownership of client-created assets
- Return required documentation
- Remove unnecessary working files
- Review any continuing support access
Appropriate engagements may use a Client Offboarding Security Checklist.
When an incident is suspected, move from signal to control.
If Struktekale becomes aware of a suspected security incident affecting client information under our control, the operating priority is to assess the situation, contain relevant access, preserve information needed to understand what occurred and communicate where required.
Contain
Restrict relevant access, revoke permissions or rotate credentials where appropriate.
Understand
Investigate what occurred and preserve the information needed to assess impact.
Communicate
Coordinate with the affected client and other relevant parties where required.
Correct
Document the event, implement corrective action and review affected systems and processes.
Relevant security events may be recorded internally to support investigation, corrective action and future prevention.
Shared Operating Boundary
Client-controlled systems remain client-controlled.
Many systems involved in a Struktekale engagement remain owned, hosted and administered by the client or the client’s technology providers.
Our controls address our access and handling. They are not intended to replace the client’s broader information-security, privacy, compliance or IT program.
Employee access
User provisioning
Internal permissions
Endpoint security
Device management
Backups
Internal security policies
Other vendors’ access
Platform configuration
Business continuity
Controls can scale with the engagement.
For work involving sensitive systems, substantial financial information, regulated information or broader infrastructure access, additional requirements may be agreed before access is provided.
Data Processing & Security Addendum
Engagement-specific obligations covering data handling and security.
Client Access Inventory
A record of systems, accounts, permissions, owners and removal dates.
Approved Tools / Subprocessor Register
Visibility over the providers approved for delivery.
Data Retention & Deletion Log
Documented handling of information at the end of its required lifecycle.
Client Offboarding Security Checklist
Evidence that access, assets and continuing permissions were reviewed.
Security Incident Log
A structured internal record supporting follow-up and prevention.
The level of documentation should reflect the nature of the engagement, the systems involved, the sensitivity of the information and the access actually required.
Security + Vendor Requirements
Set the rules before access begins.
If your organization has requirements covering approved software, confidentiality, data retention, AI usage, vendor onboarding, privacy or security review, those requirements can be discussed before an engagement begins.
Discuss security requirements →
Last updated
September 2026
September 2026
This page describes Struktekale’s current operating approach to client information and security. It is provided for general informational purposes and does not create additional contractual obligations, warranties, certifications or guarantees. Specific obligations applicable to an engagement are governed by the applicable agreement between Struktekale and the client.