Access Control Policy

Policy

Physical and electronic access to Confidential and Internal information and computing resources must be controlled. Access is granted on a need-to-know basis and must be authorized by the supervisor, application or information owner, and the Information Security Officer where appropriate.

Access Methods

Acceptable access-control models include:

• Context-based access, including time, location, authentication strength, and device posture.
• Role-based access mapped to job responsibilities and business activities.
• User-based access tied to the identity of the authorized individual.

Identification and Authentication

Systems used to store Confidential or Internal information require user identification and authentication. Accounts must meet these requirements:

1. Login information cannot be shared with third parties.
2. Individual accounts must not be shared.
3. Shared credentials require Information Security Officer approval, must follow the Password Control Policy, and must be shared only through the approved Apple Passwords shared-group model.
4. Initial or temporary login information must be changed after first login.
5. Default accounts must be disabled or have passwords changed.
6. Temporary accounts must have defined end dates and be disabled on that date.
7. MFA must be enabled where the system supports it.

Primary Identity Accounts

Core 12 maintains a small set of primary identity accounts for each employee so access can be provisioned, reviewed, and removed consistently.

Account	Required use	Minimum control expectation
Microsoft 365 account	Primary Core 12 business identity. Use for SSO, Microsoft services, email, Teams, device or application access, and conditional access wherever practical.	Company-managed account using the employee's Core 12 email address, MFA, conditional access where available, and inclusion in onboarding, access review, and offboarding.
Apple Account	Apple platform identity for iCloud on Core 12-managed Apple devices and Apple Passwords access. The employee may use a personal Apple Account for iCloud/password access, or Core 12 may issue a company Apple Account when the employee does not want to use a personal account.	Apple Passwords shared-group access is controlled by Core 12 through the services@core12.com Apple Account. Personal Apple Account use does not authorize personal email or personal cloud storage for Core 12 business collaboration outside this approved purpose.
Google services account	Created as needed for Google services, client sharing, Google Drive, analytics, advertising, or other collaboration workflows that require a Google identity.	Must use the employee's Core 12 company email address. Personal Google accounts must not be used for Core 12 or client collaboration, file sharing, analytics, advertising, or administrative access.

SSO and Collaboration Account Rules

1. Microsoft 365 must be used as the preferred SSO and conditional-access identity wherever supported by the application, vendor, or client workflow.
2. New service onboarding must evaluate whether named user accounts, SSO, role-based access, or delegated administration can replace shared credentials.
3. Client collaboration accounts must use the approved Core 12 identity for that platform. Personal accounts must not be used for client systems, client files, Core 12 files, analytics, advertising platforms, repositories, or administrative consoles.
4. Exceptions must be approved by the Information Security Officer, recorded with the service or personnel record, and reviewed at the next access review.

Access Reviews

All IT systems with identification/authentication must be reviewed at least quarterly. Reviews verify that accounts are still in use, the account owner is supposed to access the system, the role still requires the same level of access, MFA is configured where available, and shared Apple Passwords group membership is still appropriate.

Access reviews must include the employee's primary identity accounts, privileged accounts, shared-password group membership, client-collaboration accounts, and any approved personal-account exceptions.

Onboarding, Role Change, and Offboarding

1. Onboarding must provision the required Microsoft 365 account and any needed Apple Account, Google services account, password-manager access, authenticator setup, and shared Apple Passwords group membership.
2. Role changes must update Microsoft 365 groups, Google access, client collaboration access, Apple Passwords shared-group membership, and service-specific roles.
3. Offboarding must remove or disable Microsoft 365 access, Google service access, Apple Passwords shared-group membership, client collaboration access, service-specific accounts, sessions, tokens, and approved personal-account exceptions.
4. Shared credentials must be rotated when offboarding, role change, or group-membership changes create a risk that access could continue outside the approved group.

Management Repo Use

• Track system/service access requirements on IT Service, Web App, Desktop App, and Personnel records.
• Track periodic access reviews through the appropriate review issue template.
• Track primary identity account requirements, approved Apple Account choices, Google services account creation, shared Apple Passwords group membership, and personal-account exceptions on Personnel or access-review records.
• Open risks for access exceptions, missing MFA, personal-account use outside this policy, shared-account use, incomplete offboarding, or systems without adequate owner review.