Skip to content

Access Control Policy

Access control POLICY

Version history

Version Number Date Description Created By Approved By
0.1 17/Apr/2024 Initial Copy [Name] [Name]
0.2 18/Jun/2024 Approved [Name] [Name] [Name]
0.3 28/Aug/2026 Knowledge kernel, AI/agents, control alignment Knowledge steward [Name]

Purpose

The purpose of this policy is to define the rules for provisioning and revocation of access for various information, information assets, information systems, as well as information processing facilities of tecciance.

Scope

This policy applies to all information, information assets, information systems, and information processing facilities of tecciance.

Responsibilities

The primary ownership of implementing this policy is with the IST, along with all relevant teams involved in providing and revoking access to information systems.

Policy

Access Control

  • Access control shall cover all types and forms of information assets and information systems used within tecciance. Access control shall apply to the below-listed information assets and information systems:

  • tecciance application on cloud

  • Cloud environment

  • Network and its components.

  • Desktop/Laptop

  • Email

  • Code repository.

  • Other information systems used within tecciance.

  • Project Management Tools

  • Other Applications and Software

  • The Head of the concerned department shall approve all access requests.

  • Access shall be provided on a need-to-know basis, at a least-privilege basis.

  • Access provisioning to external people, contractual employees, entities, or organizations shall be controlled and appropriately approved.

Access Provisioning

  • Access provisioning requests shall be managed through email from reporting Managers or Head of Departments.

  • Shared or common access shall be avoided unless justified for business purposes. IST shall approve exceptions IST.

  • All user-level access shall be secured through usernames and passwords.

  • Administrative or privileged access shall be controlled through multi-factor authentication, wherever possible.

  • All access provisioning records, and status shall be maintained and updated through email approvals and tickets.

Access Revocation

  • Access shall be revoked immediately (On or before the last working Day) when the user separates from the organization or no longer needs to have access.

  • Access shall also be revoked or changed whenever any user changes the role or function.

  • Access revocation records shall be maintained within an email or ticket.

User Access Review

  • Access reviews shall be conducted on a periodic basis to ensure adequacy. The planned frequency of conducting all types of access reviews shall be at least quarterly.

  • Access reviews shall be conducted against the provisioned access and against the active HR list.

  • Any permissions which are found to be no longer required shall be adjusted or revoked.

  • Records of access review shall be maintained for further reference.

Procedure

Access Provisioning Process

  • Access provisioning requests shall be initiated by the HR team for the newly joined users (employees/non-employees) at the time of joining.

  • Existing users may also initiate access provisioning requests to have access to any added information system or application to which they do not have access presently.

  • All access requests should be initiated through email.

  • The HR team shall raise the access request via email, and the Department Head shall approve the same.

  • For any administrative-level access request raised through email, the approval shall be given by the IS team, and access shall be granted for a defined period.

  • Email requests duly approved shall be forwarded/assigned to the respective teams for provisioning of access.

  • The access provisioning responsibilities are as below:

  • For Network, Internet, IT infrastructure - IT Team

  • For tecciance Application - IT Team

  • For Cloud infrastructure - Cloud/DevOps Team

  • For Email - IT Team

  • For source code, database - Cloud/DevOps Team

  • For Networking devices - IT Team

  • For other Tools - IT Team

  • Any other information system - IS Team

  • All-access requests approved within the email shall be managed by the respective responsible teams within the minimum possible time.

  • Once the necessary access is provisioned, the credentials shall be communicated to the concerned user, and the requester shall be informed about the completion of the task.

  • Whenever any administrative-level access is requested and to be provided, multi-factor authentication (MFA) shall be considered (if possible). MFA using login/password and Google Authenticator Token may be used for authentication.

  • Users shall be prompted to change their default passwords on the first login.

Access Revocation

  • Access revocation requests may be initiated in any of the below situations:

  • When any employee leaves tecciance or is terminated,

  • When the contract/agreement of any non-employee is expired or terminated before expiry,

  • When any access provided to any employee/non-employee is no longer required.

  • Access revocation requests shall be raised by the HR team in case of employee or non- employee leaving or termination through email.

  • Access revocation requests may be raised by any Head of department for the employee/non- employee whose access needs to be revoked for any application or information system. Such requests shall be raised through email.

  • Once the request is raised, approval shall be provided, wherever necessary, by the respective approving person. Such approvals shall be done through email as applicable.

  • Whenever any administrative access is required to be revoked/removed, approval from IST shall be taken through email.

  • The request shall be forwarded to the concerned team for execution.

  • The concerned team shall deactivate/remove/revoke the access by referring to the access control matrix for the concerned user (employee/non-employee).

  • In case of an email request raised for revocation, the same shall be updated and closed post removal of access.

  • When necessary, the requestor or initiator of the request shall be intimated about the completion of the task over email.

Access Review

  • Access Reviews shall be conducted for all applications, networks, information systems, etc., on predefined intervals by the responsible teams.

  • Access reviews shall be conducted at least quarterly for all access provided to information systems, networking devices, or tools.

  • Access Reviews shall be conducted referring to the access provision. The access provision/revocation records, as well as approval records maintained within the email, may also be referred for review.

  • The reporting managers or Head of departments shall be involved in conducting the periodical access rights review.

  • Any discrepancies identified during reviews shall be immediately addressed, and relevant change requests/tickets shall be raised for revoking access (if applicable).

  • Records of conducting access review shall be maintained for future audit and review processes.

  • Results of the access review shall be communicated to the IS team, which in turn shall brief the Management during the quarterly reviews.

Terms and definitions

The following provides an explanation of various terms used within this document: IST: Information security team.

  • LT: Leadership team

  • Logical Access: Logical access controls are tools and protocols used for identification, authentication, authorization, and accountability in computer information systems.

  • Access Control: Access control is a security technique that regulates who or what can view or use resources in a computing environment. Logical access control limits connections to computer networks, system files, and data.

  • MFA: Multi-factor authentication

  • Privilege: A special right, advantage, or immunity granted or available only to a particular person or group.

  • Privileged Access: Privileged access is a type of administrative or super-user access that allows for full control of critical computer systems and applications anywhere and at any time. Single Sign-On: Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID and password to any of several related yet independent software systems.

  • Password: A secret word or phrase consisting of a string of characters that allows access to a computer system or service.

Artificial intelligence, software agents, and organizational knowledge

This section is added in version 0.3 so the policy applies equally to employees and to software agents, and so reusable knowledge stays provenanced.

Software agents, bots, service accounts, CI jobs, and coding assistants are identities. They are in scope of this policy wherever people are.

Every retrieve or use of organizational knowledge or classified data requires a verified identity, a stated purpose, and a classification ceiling. Missing purpose is deny.

AI may extract, draft, rank, or propose. AI shall not approve access, classify or reclassify information, set reuse rights, waive a control, merge to a protected branch, or treat search ranking as truth.

Approved reusable knowledge is a governed claim with source, owner, lifecycle, applicability, and limitations. Raw chat, tickets, and scanner output are not approved knowledge.

Embeddings, summaries, caches, and compiled agent skills are derivatives. Withdrawal, reclassification, or destruction of a source shall propagate to derivatives.

Secrets, credentials, production data dumps, and Restricted (including client/PHI) material shall not be pasted into public generative-AI services or stored in vector indexes unless an authorized path and agreement exist.

HIPAA-regulated PHI is out of default scope. Enable the HIPAA pack and a business-associate path before any PHI is processed by agents or knowledge indexes.

Change to a must procedure (including knowledge used by agents) is a change under the Change / Release procedure and SOC 2 CC8.1. Agents cannot approve that change.

Access requests should be recorded in the identity or ticketing system of record. Email may evidence a request but shall not be the only durable access register (SOC 2 CC6).

Privileged and remote access shall use multi-factor authentication. 'Wherever possible' is not an exemption for administrator, cloud, source-code, or production access.

Knowledge-portal and kernel retrieval is data access. Log requester, purpose, classification ceiling, and the policy decision.

Service accounts and agents shall be provisioned, reviewed quarterly, and revoked with the same cadence as human users.