Loading…
Loading…
Security, IP & Engineering Standards
Giving an external engineering team access to repositories, credentials, environments, or product data requires more than a promise. This page explains how 6sense HQ handles access, intellectual property, engineering delivery, handover, and offboarding—and what should be agreed before work begins.
Before Sensitive Access
When you engage 6sense HQ for a Code Audit, Software Project Rescue, development engagement, or technical partnership, six areas should be clear before sensitive access is granted.
Your agreement should state what you own, when ownership transfers, and whether any rights are retained after the engagement.
The engagement should define where code lives, who holds administrator access, and how engineering access is granted.
Production, staging, cloud, database, and third-party access should be limited to what the work actually requires.
Engineering work should remain traceable through the agreed repository, project workflow, reviews, and delivery process.
Documentation, deployment context, open issues, and operational knowledge need a defined destination when work is handed over.
Access removal, credential rotation where appropriate, and final ownership checks should be part of closing an engagement.
Access Lifecycle
For the Codebase & Production Readiness Audit, 6sense HQ already confirms required access against the agreed audit scope before work starts. The audit may require repositories, environments, credentials, architecture context, deployment access, observability, or runbooks depending on scope. That principle should become the foundation of the broader 6sense access policy.
Confirm exactly which repositories, environments, services, documentation, and systems are necessary for the agreed work.
Code Ownership & Contracting
6sense HQ's existing public pages state that project IP transfers to the client at project completion, including the codebase, design assets, API documentation and deployment configuration, and that 6sense HQ retains no licence rights to the client's product. This is exactly the kind of answer buyers need—but the wording should be taken from the actual current contract rather than copied from marketing pages.
Verify before publishing: Verify against current MSA/SOW before publishing.
The final policy should clearly answer:
What project IP the client owns.
When ownership transfers.
Whether payment or other contractual conditions affect transfer.
How pre-existing 6sense tools or reusable components are treated.
How open-source and third-party components are treated.
Whether 6sense retains any licence or reuse rights.
What confidentiality obligations survive termination.
MSA / SOW
Show the actual IP/confidentiality clause once legal confirms the current contract language. Client names and commercial terms removed.
| Contract clause | What the contract says |
|---|---|
| You own | [INSERT CONTRACT-VERIFIED CLIENT IP SCOPE] |
| Ownership transfers | [INSERT EXACT TRANSFER POINT] |
| 6sense retains | [INSERT EXACT EXCEPTIONS OR “NO RIGHTS” IF CONTRACTUALLY TRUE] |
| Third-party / open-source | [INSERT ACTUAL CONTRACT TREATMENT] |
You own
Ownership transfers
6sense retains
Third-party / open-source
Repository & Credential Controls
The final page should give a direct answer for each category below. Do not publish generic security best practices—these answers must describe what 6sense actually does.
Verify before publishing: Are client-owned GitHub/GitLab repositories preferred by default? Who retains administrator ownership? What exceptions exist?
Verify before publishing: MFA requirements, SSO where applicable, named-user requirements, and shared-account restrictions.
Verify before publishing: Approved password/secrets management system, prohibited sharing methods, and rules around local storage.
Verify before publishing: Who may receive production access, who approves it, and whether temporary/time-limited access is used.
Verify before publishing: Repository cloning, local databases, production-data downloads, backups, and device-storage requirements.
Verify before publishing: How access is reviewed when team members change and how it is revoked at engagement end.
Engineering Delivery Controls
Security is not only about passwords and repository permissions. The engineering workflow determines whether changes are reviewable, testable, attributable, and recoverable.
Verify before publishing: Jira or equivalent requirements for scoped engineering work.
Verify before publishing: Pull-request requirements and required reviewer roles.
Verify before publishing: QA, automated testing, regression testing, and client acceptance rules.
Verify before publishing: Automated build, testing, and deployment controls used by engagement type.
Verify before publishing: Who can approve and execute production deployments.
Verify before publishing: Escalation process, incident recording, and contractual client-notification requirements.
Traceable delivery
Use anonymized first-party screenshots rather than illustrations once the exact standard is confirmed.
Task linked to the engagement backlog.
Change visible in the agreed repository.
Required reviewer role confirmed.
Testing/acceptance evidence attached.
Approved deployment path recorded.
AI & Client Code
6sense HQ publicly describes its development process as AI-assisted. That means a buyer sharing proprietary source code reasonably needs to know what happens when AI tools are used. This section becomes one of the strongest trust differentiators once the actual policy exists.
Verify before publishing: Which AI coding and analysis tools are approved?
Verify before publishing: Can client source code be submitted to hosted AI services?
Verify before publishing: What data-retention/training settings are required?
Verify before publishing: Are secrets, PII, production data, or regulated data prohibited from AI tools?
Verify before publishing: Are there engagements where AI tools are disabled entirely?
Verify before publishing: What human review is required for AI-assisted code or analysis?
Handover & Offboarding
A trustworthy handover is more than sending a ZIP archive. The closeout process should address code, administrative access, documentation, environments, credentials, unresolved risks, and operational knowledge.
Confirm the agreed repositories, deliverables, and administrative ownership are in the correct hands.
Remove team access that is no longer required and identify credentials that need to be rotated.
Transfer the agreed technical documentation, deployment context, runbooks, open issues, and architectural decisions.
Record any remaining access, retained materials, support obligations, or exceptions that still require action.
Verify before publishing: Actual 6sense offboarding/handover checklist required as evidence.
Security & Engineering Evidence
Do not use generic shield graphics, padlock illustrations, or stock cybersecurity photography as the main evidence. Use real 6sense operating evidence with short captions explaining what each item proves.
| Evidence | Type | What it proves |
|---|---|---|
| Redacted MSA/SOW excerpt | Contract clause | Shows the actual IP/confidentiality clause once legal confirms current wording. |
| Repository-access screenshot | Access control | Anonymized example showing how engineering access is assigned to a project repository. Client names, repository names, and sensitive identifiers removed. |
| Jira + PR/engineering screenshot | Delivery evidence | Demonstrates traceable work and review across the agreed engineering workflow. |
| Access / onboarding checklist | Operating document | Redacted actual operating document used when granting engagement access. |
| Offboarding / access-removal checklist | Operating document | Shows that removal is part of the process, not an afterthought. |
| PM / engineering team photo | Identity | Supporting identity evidence for the people who run the process—not proof of a security control. |
Redacted MSA/SOW excerpt
Repository-access screenshot
Jira + PR/engineering screenshot
Access / onboarding checklist
Offboarding / access-removal checklist
PM / engineering team photo
Evidence cards distinguish operating methodology from client findings. Sensitive identifiers are removed before publication.
Ownership, access, credentials, AI handling, and what happens when an engagement ends.
Primary BOFU connection
Rescue conversion
First-party delivery proof
Qualification path
Reviewed by: [CONFIRM: Operations / Engineering leader] · Last reviewed: [INSERT REAL REVIEW DATE] · Policy applies to: Confirm whether Audit, Rescue, Development, and White-Label follow the same standard or have engagement-specific exceptions.
Misty evergreen forestBefore access is granted, we can walk through scope, ownership, repository access, credentials, environments, AI-tool requirements, and any security conditions relevant to your engagement.
