Broad shares exposed trade secrets; Just?in?Time access on Okta–SharePoint with manager and Legal approvals

Overview

Trade secret materials sat in broadly shared folders and collaboration drives, so employees and contractors could browse sensitive designs, pricing models, and source documents without a clear business need. Legal relied on policies and NDAs, but access controls did not reflect those expectations. Intelligex ran a permissions audit, classified sensitive repositories, and introduced just?in?time (JIT) access with manager and Legal approvals, time?bounded grants, and full logging. Access aligned to the principle of least privilege, requests followed a governed path, and evidence of who accessed what—and why—lived in one place. Existing identity, collaboration, and ticketing tools remained in place. The program reinforced trade secret protection practices informed by resources from the World Intellectual Property Organization (WIPO) and aligned to role?based access control principles from NIST (NIST RBAC, least privilege).

Client Profile

• Industry: Enterprise technology and manufacturing
• Company size (range): Global workforce with engineering, operations, and sales using cloud collaboration and on?prem file shares
• Stage: Policies and NDAs in place; shared drives and workspaces with permissive groups; manual permissions maintenance; limited logging and attestation
• Department owner: Legal & Compliance (IP/Trade Secret, Privacy, and Legal Operations)
• Other stakeholders: IT/Identity, Security/GRC, Engineering, Product, HR, Procurement/Vendor Risk, Internal Audit

The Challenge

Shared drives grew over years of reorganizations and acquisitions. Engineering and product teams used inherited folders, while enterprise collaboration tools added new spaces with default group access. Legacy projects marked “confidential” remained open to large distribution lists. Contractors and former team members retained access because groups were nested and owners were unclear. Legal could not point to a single record showing who accessed a given design, when access was granted, and under what approval.

Request and approval paths were ad hoc. Employees asked a colleague with admin rights, or IT granted group membership to unblock work. Legal guidance emphasized trade secret care, but approvals for exceptions were buried in email threads without expiry dates or review points. When incidents were investigated, logs captured some events but did not clearly link access to a business need or to the approving manager and counsel.

The result was exposure and friction. Teams either overshared to avoid delays or waited while someone with admin rights hunted for the right group. Neither pattern aligned with trade secret protection obligations or operational reality. Leadership needed a consistent way to align access with need, record decisions, and monitor exceptions without blocking legitimate work.

Why It Was Happening

Permissions followed tools, not data criticality. Collaboration platforms and file systems provided powerful sharing, but there was no central classification of trade secret repositories or a standard model for access by role, project, and tenure. Group sprawl and nested memberships hid who actually had access, and periodic reviews relied on manual exports and spreadsheets.

Policy was not embedded in the path of work. The company had a trade secret policy and NDAs, yet requesters bypassed Legal because the process was slow or unclear. There was no JIT pathway with time bounds, no reason codes tied to approvals, and no consistent log that linked an access grant to the data it enabled.

The Solution

Intelligex established a permissions governance layer: a one?time and recurring audit of sensitive repositories, a JIT access workflow with manager and Legal approvals, time?boxed grants, and centralized logging. Repositories containing trade secrets were classified and tied to approved access patterns by role and project. Users requested access through a short form with business justification; requests routed to the manager and Legal for approval with reason codes; approved access provisioned automatically for a defined period, then expired unless renewed. All grants and reads were logged and surfaced in dashboards for review. The approach aligned to trade secret protection practices (WIPO) and enforced role?based controls consistent with NIST RBAC and least privilege.

• Integrations: Identity provider (for example, Okta or Azure AD) for group and role mapping; collaboration platforms (Microsoft 365 SharePoint/OneDrive, Google Drive) and on?prem file shares for permission changes; service desk (for example, ServiceNow or Jira) for JIT requests and approvals; SIEM for centralized logging; DLP to flag risky shares and downloads.
• Repository classification: Catalog of trade secret repositories with owners, data categories, and approved access patterns; tagging in collaboration tools; owner attestation and periodic recertification.
• JIT access workflow: Request form with justification, project, and duration; manager and Legal approvals with reason codes; automated provisioning and expiry; exception handling for urgent needs.
• Least?privilege enforcement: Default deny for sensitive repositories; scoped groups by project and role; break?glass process with automatic notifications and short durations.
• Monitoring and logging: Access grants, reads, and downloads forwarded to SIEM; alerts for anomalous access patterns; dashboards for owners and Legal to review active grants and upcoming expirations.
• Remediation and cleanup: Initial permissions audit to collapse broad groups, remove inactive accounts, and document residual risks; migration playbooks to separate archival content from active trade secrets.
• Security and privacy: Role?based access to request queues and logs; counsel?only notes for sensitive matters; minimal personal data in notifications; immutable logs and retention aligned to records policy.

Implementation

• Discovery: Mapped sensitive repositories and owners across collaboration platforms and file shares; inventoried groups and nested memberships; sampled incidents and prior approvals; gathered Legal, Security, IT, and business stakeholder requirements for approvals, durations, and evidence.
• Design: Authored the repository classification schema and ownership model; defined JIT request forms, approver paths, and default durations; set least?privilege patterns and exception criteria; planned identity and file system touchpoints; outlined dashboards and SIEM alerts; established change control for rules and templates.
• Build: Implemented the repository catalog and tagging; configured the service desk workflow with manager and Legal approvals; integrated identity and collaboration platforms for automatic provisioning and expiry; connected logs to the SIEM; enabled dashboards for owners and Legal.
• Testing/QA: Piloted JIT on a subset of repositories; validated provisioning, expiry, and notifications; simulated break?glass and exception paths; verified log capture and dashboards; tuned request fields, durations, and messages from owner and counsel feedback.
• Rollout: Launched JIT for high?risk repositories first; collapsed broad groups and removed inactive access in waves; expanded to remaining trade secret stores; retained legacy request paths as a monitored fallback early on; tightened default deny and expiry after stable cycles.
• Training/hand?off: Delivered guides for requesters and managers on JIT and durations; trained Legal on approval queues and reason codes; briefed repository owners on dashboards and recertification; updated SOPs and exception playbooks; transferred ownership of rules, catalogs, and dashboards to Legal Ops and Security under change control.
• Human?in?the?loop review: Established recurring reviews of exceptions, anomalous access patterns, and catalog accuracy; recorded decisions with rationale and effective dates; updated access patterns, durations, and owner assignments accordingly.

Results

Access to trade secrets matched business need. Sensitive repositories defaulted to deny, JIT requests captured the why and for how long, and manager and Legal approvals put policy into practice without clogging daily work. Grants expired on schedule, and owners saw live dashboards of who had access and when it would end.

Exposure decreased and evidence improved. Broad groups were retired, inactive access removed, and reads and downloads were logged with context. When questions arose, Legal produced a case record showing the request, approvals, provisioning and expiry events, and activity logs. Core platforms stayed the same; the change added classification, workflow, and governance between identity, collaboration tools, and Legal.

What Changed for the Team

• Before: Broad groups could browse sensitive folders. After: Sensitive repositories defaulted to deny with JIT access by project and role.
• Before: Access requests lived in email. After: A request workflow captured justification, approvers, and durations with automated provisioning and expiry.
• Before: Group sprawl hid actual access. After: A catalog tied repositories to owners, approved patterns, and dashboards.
• Before: Exceptions were informal. After: Time?boxed exceptions carried manager and Legal approvals with reason codes.
• Before: Logs were sparse and scattered. After: Grants and activity flowed to the SIEM with review dashboards for owners and Legal.
• Before: Cleanup was episodic. After: Recertification and alerts prompted ongoing hygiene.

Key Takeaways

• Classify what matters; identify trade secret repositories and assign owners and approved access patterns.
• Embed least privilege; default to deny and provide JIT access with business justification and time bounds.
• Make approvals traceable; require manager and Legal sign?off with reason codes in a system of record.
• Automate expiry and reviews; let grants end by default and surface dashboards for owners to recertify.
• Centralize logs; route grants and reads to a SIEM and monitor for anomalies.
• Integrate, don’t replace; keep identity, collaboration, and ticketing—add classification, workflow, and governance between them.

FAQ

What tools did this integrate with? Identity and group management ran through the existing provider (for example, Okta or Azure AD). Collaboration platforms (Microsoft 365 SharePoint/OneDrive and Google Drive) and file shares received permission changes from the JIT workflow. Requests and approvals lived in a service desk such as ServiceNow or Jira, and logs forwarded to the SIEM. Design principles aligned to NIST RBAC and least privilege, with trade secret protection guidance from WIPO.

How did you handle quality control and governance? Repository catalogs, access patterns, and approval matrices lived under Legal Ops and Security change control with owners and effective dates. Every request, approval, grant, read, and expiry wrote to immutable logs. Maker?checker applied to high?risk repositories and break?glass exceptions. Periodic recertification required owners to attest to active access, and updates were tracked with release notes.

How did you roll this out without disruption? JIT launched for the most sensitive repositories first, while legacy request paths remained as a monitored fallback. Broad groups were collapsed in waves with owner communication. Default deny and expiry tightened only after dashboards and notifications proved reliable. Training and quick guides supported managers, requesters, and owners.

How did you manage contractors and vendors? Contractor access used the same JIT workflow with shorter default durations and sponsor requirements. Vendor access required a documented purpose, manager and Legal approval, and explicit expiry. Identity lifecycle events removed access automatically when engagements ended.

What about urgent needs and project sprints? A break?glass path allowed short, closely monitored access with automatic notifications to owners and Legal. These exceptions were time?boxed and visible on dashboards, and renewals required explicit approval with rationale.

How did you protect privacy and privileged analysis in logs and requests? Role?based access limited who could see request details and activity logs. Counsel?only fields stored privileged analysis, and notifications contained minimal detail with links back to the system. All access and exports were logged, and retention followed records and legal hold requirements.

How were legacy shares and nested groups cleaned up? The initial audit identified broad groups and inactive accounts. Owners received targeted remediation tasks and migration playbooks to separate archival content from active trade secrets. Nested groups were flattened where possible, and residual risks were documented with remediation timelines.