Access Control Policy

Purpose

This Policy makes sure that only the right people reach our systems and our customers' environments, and only for as long as the work needs. It limits the damage a mistake or a stolen account can do.

Scope

This Policy covers every account, system, application, network, and customer environment that Tidewell IT owns, operates, or administers, and everyone who requests, approves, or uses access to them.

Policy statements

Principles

1. Access follows least privilege and need to know: a person gets the access the role requires and nothing more.
2. Access is denied unless it has been granted on purpose.
3. Access is granted through roles where possible, and the Service Desk Lead keeps the role templates up to date.

Identity and accounts

1. Every account belongs to one person. Shared accounts are not allowed.
2. Accounts are created from role templates and are disabled when the person leaves or changes role.
3. A joiner receives accounts on the first working day. A mover's old access is removed when the new access is granted.

Authentication

1. Passphrases have at least 14 characters.
2. Multi-factor authentication is required on every staff account and on every privileged or remote access path.
3. Authentication secrets are never sent by chat, written down where others can read them, or stored in clear text.

Privileged access

1. Privileged accounts are separate from daily accounts and are used only for administration.
2. Sealed break-glass accounts exist for emergencies. Every use is logged and reviewed afterwards by the ISMS Manager.
3. Privileged sessions on production and customer systems are logged, and the logs are kept with the other security logs for 12 months.

Access to customer environments

1. Access to a customer environment is tied to a ticket and is limited in time. It expires when the ticket closes.
2. Engineers use only the tools and routes that Tidewell IT has approved for customer access.

Access reviews

1. Access to production and customer environments is reviewed every quarter. Owners confirm or revoke within 5 working days.
2. Leaver access ends by the end of the leaver's last working day.

Source code and configuration

1. Access to source code, build systems, and configuration repositories is granted by role, and changes are traceable to a person.
2. Credentials, keys, and tokens are kept in the approved secrets store and never in repositories, tickets, or chat.

Segregation of duties

1. Nobody approves their own access. Conflicting duties are given to different people, or the Change Manager approves a compensating control.

Roles and responsibilities

The Service Desk Lead owns this Policy and runs the access process. System owners approve access to their systems. The ISMS Manager reviews break-glass use. The HR Lead tells the Service Desk about joiners, movers, and leavers. Line managers confirm what their team members need.

Exceptions

An exception needs a written request to the ISMS Manager that states the reason, the risk, and an end date. Shared accounts and access without multi-factor authentication are never granted as exceptions.

Compliance and enforcement

Breaches of this Policy lead to disciplinary measures under the HR process. Access found without approval is removed at once and reported to the ISMS Manager.

Related documents

• Information Security Policy
• Acceptable Use Policy
• Access Request and Review Procedure
• Joiner, Mover and Leaver Procedure
• Secure Development and Change Policy

Review

The Service Desk Lead reviews this Policy at least once a year and after a significant change. The Management Board approves each revised version.