A company's security policies, written in 93 Compliance

1. Purpose

This policy describes how Fernhollow Health, Inc. ("Fernhollow") grants, reviews and removes access to its systems and data. The goal is simple: each person can reach only what they need for their job, every login is strongly authenticated, and access is removed quickly when it is no longer needed.

2. Scope

This policy covers every system that stores, processes or can reach Fernhollow or customer data, including:

• AWS (production accounts in ca-central-1 and us-east-1, staging, and the security/log archive account)
• Okta (identity provider)
• Google Workspace
• GitHub
• Zendesk
• Slack, Stripe, Twilio and other SaaS tools on the approved software list

It applies to all employees, contractors and service accounts.

3. Roles and responsibilities

• IT Lead (Tom Becker) owns this policy, administers Okta and Google Workspace, and provisions and removes accounts.
• Security Officer (Marcus Oyelaran) approves privileged access, oversees access reviews and keeps the review evidence.
• System owners approve access to their system and perform access reviews. Current owners: AWS – Lucía Ortega; GitHub – Lucía Ortega; Okta and Google Workspace – Tom Becker; Zendesk – Grace Liu; Stripe – Dana Whitfield; Twilio – Lucía Ortega.
• Managers request access for their team members and confirm that new access is correct.
• People & HR (Priya Raman) tells IT about joiners, movers and leavers through the HR system.

4. Policy statements

4.1 Principles

• Access is granted on the principle of least privilege: the minimum access needed to do the job.
• Access is based on role. Standard role bundles (Engineering, Customer Success, Sales, Operations, People) are defined in Okta groups. Anything outside a role bundle needs a separate approval.
• Duties are separated where practical. The person who approves access is not the person who grants it, and engineers cannot approve their own pull requests.

4.2 Authentication

• Okta single sign-on is used for every system that supports SAML or OIDC. Local accounts are disabled wherever SSO is available.
• MFA is required for every user on every system. Okta Verify with number matching, or a FIDO2 security key, are the only allowed factors. SMS and voice call factors are disabled.
• Administrators of AWS, Okta, Google Workspace and GitHub must use a FIDO2 security key.
• Passwords must be at least 14 characters. Okta blocks passwords found in common breach lists. Passwords are not forced to expire on a schedule, but must be changed immediately if compromise is suspected.
• Okta sessions expire after 12 hours. AWS console sessions expire after 1 hour. Accounts are locked for 30 minutes after 10 failed login attempts.

4.3 Granting access

• Access requests are made in the #access-requests Slack workflow, which creates a ticket naming the system, the role and the reason.
• The system owner, or the manager for a standard role bundle, approves the request in the ticket before IT grants access.
• Privileged access (AWS administrator, production database access, Okta super admin, GitHub organisation owner) also needs written approval from the Security Officer.
• New hires receive only their role bundle on day one. Within 14 days of the start date, the hiring manager confirms that the new hire's access is correct. The manager, not IT, does this confirmation.

4.4 Production and PHI access

• No one has standing access to production databases containing PHI. Engineers request time-limited access through AWS IAM Identity Center, which expires after 4 hours and is logged in CloudTrail.
• Production access is limited to the on-call engineering group (currently 6 people) and the Security Officer.
• Customer Success staff view customer data only through the admin console, which logs every record viewed.

4.5 Service accounts and keys

• Service accounts have a named human owner and are listed in the service account register.
• Long-lived AWS access keys are not allowed for people. Service keys are rotated at least every 90 days, or replaced by IAM roles.
• Secrets are stored in AWS Secrets Manager or 1Password, never in source code. GitHub secret scanning and push protection are enabled for all repositories.

4.6 Access reviews

• User access to AWS, Google Workspace, GitHub, Okta and Zendesk is reviewed quarterly by the system owner, following the Quarterly Access Review procedure.
• Privileged accounts and service accounts are included in every quarterly review.
• Accounts not used for 90 days are disabled, unless the owner documents a reason to keep them.
• Each review is signed off by the system owner and the Security Officer. Evidence (the user export, the decisions and the removal tickets) is kept for at least 3 years.

4.7 Changes and removal

• When someone changes role, access no longer needed for the new role is removed within 5 business days.
• When someone leaves, all access is removed on the same day, following the Employee Offboarding procedure. For involuntary terminations, access is removed before or during the termination meeting.
• Okta is the first system disabled, which ends single sign-on to all connected systems. Accounts outside Okta (AWS root, break-glass accounts, Stripe, Twilio) are handled from the offboarding checklist.

4.8 Break-glass accounts

• One break-glass administrator account exists for each of AWS (per account) and Okta. Credentials are stored in a 1Password vault that only the Security Officer and IT Lead can open. Any use triggers an alert to #security-alerts and must be explained in a ticket within 24 hours.

5. Exceptions

Exceptions are requested through 93 Compliance and approved by the Security Officer, for up to 90 days. Exceptions to MFA requirements are not granted.

6. Enforcement

Granting or using access outside this policy may lead to removal of access and disciplinary action, up to and including termination.

7. Review

The IT Lead reviews this policy at least once a year with the Security Officer. Changes are approved by the CEO.

Revision history