Purpose and scope
Access to NexCommand and customer environments must be limited to authorized people and services for a defined purpose. This policy covers corporate systems, source repositories, hosted services, customer integrations, field equipment, support tools and physical access relevant to information systems. It supports the approved Information Security Policy without replacing customer-specific requirements.
Every system must have an accountable owner who approves access rules and periodic review. Human resources or the contract sponsor must communicate joining, role-change and departure events. IT implements authorized changes; managers verify business need; security reviews higher-risk access. Users remain responsible for protecting credentials and reporting suspected misuse.
Identity lifecycle and authorization
Use unique identities wherever technically possible and prohibit unapproved shared accounts. Access requests must identify the individual or service, sponsoring owner, required role, information scope, purpose and duration. Verify identity and authorization before provisioning. Grant the minimum permissions needed and separate incompatible duties where required by risk or contract.
Role changes require review of old permissions as well as new access. Departures, expired contracts and revoked authority require prompt disabling under a documented process and risk-based urgency. Revoke active sessions, tokens, remote-access rights and physical credentials where relevant. Preserve necessary business records without leaving the former user's access active. Emergency removals must not wait for a routine review cycle.
Authentication and credentials
Require authentication appropriate to system risk and applicable requirements, including MFA for privileged and remote access as the baseline. Prefer stronger phishing-resistant methods where feasible and required. Password, recovery and enrollment procedures must resist unauthorized reset, credential reuse and social engineering. Do not store secrets in source code, public documents, AI prompts or shared chat.
Define account-lockout, session, recovery and lost-device procedures that maintain both security and usable access. Record approved exceptions for legacy systems with compensating controls and an expiry date. A temporary inability to use MFA must not become an indefinite bypass. Test recovery so that security controls do not depend on a single individual or device.
Privileged and support access
Separate routine user work from administration. Grant privileged access only to named competent personnel, limit its duration where practical and log relevant administrative activity. Review elevation, remote support, break-glass accounts and access to security tooling. Emergency access must have a recorded reason, authorized activation and retrospective review.
Customer support must use the agreed access route and scope. Obtain required customer authorization, restrict data exposure and revoke temporary access when the task ends. Do not copy customer data to a personal workspace for convenience. Supplier or model-provider support must not receive broader access than the contract and technical boundary permit.
Service identities, integrations and AI tools
Each service account, connector, API token and automation identity must have an owner, purpose, permission scope and credential lifecycle. Prefer scoped credentials and managed secret storage. Avoid giving an AI tool or integration administrator rights merely to simplify setup. Review outbound destinations, data fields and permitted write operations.
Enforce end-user permissions in retrieval and workflows. A model's response must not expose data that the user could not lawfully access through the underlying system. Test role changes, removed users, cross-tenant boundaries and indirect access through exports. Consequential writes require the authorization and approval controls defined for that workflow.
Review, monitoring and evidence
System owners must review access at a documented risk-based interval, with privileged and sensitive systems reviewed more frequently. Compare actual permissions with current personnel, roles and contracts; remove unjustified access and verify completion. Monitor relevant authentication failures, suspicious elevation and account changes, with an assigned responder.
Retain requests, approvals, provisioning evidence, reviews, exception decisions and relevant logs. For regulated engagements, map the process to the required control baseline and assessment evidence; a policy alone does not demonstrate implementation. See NIST guidance and CMMC scoping.
Records, exceptions and review
The policy owner must maintain the records needed to demonstrate implementation: applicable requirements, named responsibilities, training, approvals, exceptions, reviews and corrective actions. Records must be access-controlled, retained under the applicable retention schedule and protected from unauthorized amendment or disposal. Legal holds and contract-specific retention requirements take precedence over routine deletion.
An exception must identify its scope, business reason, risk, compensating measures, accountable approver and expiry date. It must be approved before the affected activity proceeds and reviewed when circumstances change. No exception can authorize unlawful conduct, remove a contractual obligation or conceal a nonconformity. Unresolved issues must be escalated to executive management and the relevant professional adviser.
The policy owner reviews this policy at least annually and after a material legal, business, product or incident-driven change. Revisions require authorized approval and document control. Supporting procedures, responsibility assignments and implementation evidence are controlled records. Statements of certification or contractual compliance must identify their scope and supporting evidence.