Electronically Signed By:
Isa Hasenko
Access Control Policy
Organization: Fintable, Inc.
Owner: Security & Compliance
Approved by: Isa Hasenko
Approval Date: 2025 October 10
Review Cadence: Annual or upon material change
1) Purpose
This Access Control Policy establishes the requirements and processes for
managing workforce access to Fintable, Inc.'s systems, applications, data, and
infrastructure. The policy ensures that access is granted based on least
privilege and business need, properly authorized, regularly reviewed, and
promptly revoked when no longer required. This supports compliance with the
Gramm-Leach-Bliley Act (GLBA), FFIEC guidance, SOC 2 Trust Services Criteria
(CC6), and ISO/IEC 27001 requirements.
2) Scope
This policy applies to all Fintable employees, contractors, temporary staff,
and interns ("workforce members") who require access to company systems,
applications, databases, infrastructure, or data classified as Internal,
Confidential, or Restricted. It covers all access types including production
systems, staging environments, development environments, databases, source code
repositories, administrative interfaces, cloud platforms, corporate
applications (Google Workspace, Slack, etc.), VPN access (Tailscale), SSH
access to servers, and customer data repositories.
3) Definitions
- Access: The ability to view, modify, create, or delete data or system
resources, or to execute commands on systems.
- Least Privilege: Granting users only the minimum level of access required to
perform their job duties.
- Need-to-Know: Access to sensitive information is restricted to individuals
who require it to fulfill specific job responsibilities.
- Privileged Access: Administrative or elevated permissions that allow
modification of system configurations, access to sensitive data, or override of
security controls (e.g., sudo, database admin, production deployment).
- Access Review: Periodic verification that user access rights remain
appropriate for current job responsibilities.
- Segregation of Duties: Separation of conflicting responsibilities among
different individuals to prevent fraud and error.
4) Access Control Principles
4.1) Least Privilege
All workforce members shall be granted the minimum access necessary to perform
their assigned duties. Default access shall be read-only or no access unless
write or administrative privileges are justified and approved.
4.2) Need-to-Know
Access to Restricted and Confidential data, as defined in the Information
Classification & Handling Policy, shall be granted only to individuals with a
demonstrated business need.
4.3) Role-Based Access Control (RBAC)
Access shall be assigned based on job roles with predefined permission sets.
Standard role templates are maintained for common positions (e.g., Engineer,
Support Specialist, Finance).
4.4) Segregation of Duties
Critical functions shall be divided among multiple individuals where feasible.
For example, code deployment to production requires peer review; financial
transactions require separate approval; and security configurations require
dual authorization for high-risk changes.
4.5) Identity and Authentication
All access must be authenticated through approved identity providers (Google
Workspace SSO). Multi-factor authentication (MFA) is mandatory for all accounts
accessing company systems. No shared accounts or generic credentials are
permitted except for documented break-glass accounts stored offline and tested
quarterly.
5) Access Request Process
5.1) Request Initiation
Access requests must be initiated through one of the following methods:
- New hire onboarding: Manager submits access requirements as part of the
onboarding checklist
- Role change: Manager or employee submits request detailing new access
requirements and justification
- Project-based: Project lead submits request with business justification and
required duration
All requests must specify the systems/applications, level of access required,
business justification, and expected duration (permanent for standard role
access, or temporary with expiration date).
5.2) Approval Workflow
Access approvals are required based on the following matrix:
Access Type | Required Approvals
-----------------------------------|---------------------------------------
Standard role-based access | Direct manager
(non-production, non-privileged) |
|
Production system access | Direct manager + Engineering Lead
(read-only) |
|
Production database access | Direct manager + Engineering Lead +
(read or write) | Security & Compliance
|
Privileged/administrative access | Direct manager + Engineering Lead +
(sudo, infrastructure, deployment) | Security & Compliance
|
Restricted data access (customer | Direct manager + Data Owner +
financial data, PII) | Security & Compliance
|
Temporary elevated access | Direct manager + Security & Compliance
| (max 30 days, with documented reason)
Junior personnel (less than 6 months tenure) are prohibited from production
database access and privileged system access unless explicitly approved by
Security & Compliance with documented exceptional business need.
5.3) Approval Timeframes
Standard requests shall be approved or denied within two (2) business days.
Urgent requests (same-day access required) must be escalated to Security &
Compliance and require documented business justification. Emergency access may
be granted provisionally with post-hoc review within one (1) business day.
6) Access Provisioning
6.1) Provisioning Process
Upon approval, access shall be provisioned by the appropriate system owner or
administrator within one (1) business day for standard requests, or within four
(4) hours for approved urgent requests. All provisioning actions must be
documented with the request ticket number, approver, date, and specific
permissions granted.
6.2) Account Creation
User accounts shall be created using the individual's corporate email address
as the unique identifier. Naming conventions shall follow the format:
[email protected]. Service accounts for automation must follow the
format: svc-[purpose] and require Security & Compliance approval with
documented ownership and rotation schedule.
6.3) Initial Access and Onboarding
New hires receive initial access based on their role template within their
first day of employment. Initial access includes Google Workspace, Slack,
Tailscale VPN, and non-privileged development environment access. Additional
access requests follow the standard request process after onboarding.
6.4) Technical Implementation
Access shall be provisioned through approved mechanisms:
- Google Workspace: SSO with MFA mandatory; role-based groups
- SSH access: Per-user SSH keys only; keys registered in authorized_keys with
owner attribution; MFA required for bastion access
- Database access: Individual database roles; no shared credentials; connection
logging enabled
- Cloud platforms: Individual accounts; role-based IAM policies; MFA mandatory
- Code repositories: Individual accounts; team-based permissions; MFA mandatory
- Secrets management: Shared only via Apple iCloud Keychain; never plaintext
7) Access Modification
7.1) Role Changes and Transfers
When a workforce member changes roles, their manager must submit an access
modification request within two (2) business days of the role change. Access no
longer required for the new role shall be removed within five (5) business days.
New access required for the new role follows the standard request and approval
process.
7.2) Temporary Access Elevation
Temporary access elevation (e.g., for specific projects or troubleshooting)
requires manager and Security & Compliance approval. Temporary access must have
a defined expiration date (maximum 30 days) and is automatically reviewed for
revocation at expiration. Extensions require re-approval with updated
justification.
8) Access Revocation
8.1) Termination
Upon termination (voluntary or involuntary), all access must be revoked
immediately. The termination checklist includes:
- HR notifies Security & Compliance and IT immediately upon termination decision
- Google Workspace account suspended within one (1) hour of termination
- VPN access (Tailscale) revoked within one (1) hour
- SSH keys removed from all systems within four (4) hours
- Database access revoked within four (4) hours
- Code repository access revoked within four (4) hours
- Company-issued devices remotely wiped or physically retrieved
- All pending access requests canceled
8.2) Extended Leave
For extended leave (exceeding 30 days), privileged and production access may be
suspended and reactivated upon return with manager approval.
8.3) Automated Revocation
Accounts inactive for 90 consecutive days are automatically flagged for review
and may be disabled pending manager confirmation. Service accounts are exempt
but must be documented and reviewed quarterly.
9) Access Reviews and Recertification
9.1) Regular Access Reviews
Access reviews shall be conducted according to the following schedule:
Review Type | Frequency | Responsibility
-----------------------------------|------------------|----------------------
All privileged access | Quarterly | Security & Compliance
Production system access | Quarterly | Engineering Lead
Restricted data access | Quarterly | Data Owner + Security
| | & Compliance
All workforce access | Annually | Managers + Security &
(comprehensive review) | | Compliance
Service accounts | Quarterly | Security & Compliance
9.2) Review Process
During access reviews, managers and system owners verify that each user's
access remains appropriate for their current role and responsibilities.
Reviewers must certify that access follows least privilege principles.
Inappropriate or excessive access must be revoked within five (5) business days
of identification. All reviews must be documented with reviewer name, date, and
findings.
9.3) Role Change Triggers
In addition to scheduled reviews, access must be reviewed and adjusted
immediately upon promotion, demotion, lateral transfer, or change in job
responsibilities.
10) Privileged Access Management
10.1) Privileged Access Definition
Privileged access includes sudo/root access on servers, database administrator
roles, infrastructure administrative access (networking, firewalls), cloud
platform administrative consoles, deployment and CI/CD pipeline access,
production secret and encryption key access, and security tool administrative
access.
10.2) Additional Controls for Privileged Access
Privileged access requires:
- Dual approval (manager + Security & Compliance)
- MFA mandatory with hardware token or biometric authentication
- Session logging and monitoring
- Quarterly recertification
- Annual background check for personnel with privileged access to customer data
- Documented break-glass procedures for emergency access
10.3) Break-Glass Accounts
Emergency break-glass accounts with privileged access are stored offline in a
secure location with restricted physical access. Break-glass account usage
requires dual authorization and must be logged with full audit trail. All
break-glass account usage is reviewed within one (1) business day with
documentation of justification. Break-glass credentials are rotated immediately
after use and tested quarterly.
11) Remote Access
11.1) VPN Requirement
All remote access to company systems, customer data, or production
environments must occur through the corporate VPN (Tailscale). Direct access to
production systems from public networks is prohibited.
11.2) Endpoint Requirements
Devices accessing company systems must meet security requirements defined in
the Employment Screening and Acceptable Use Policy and Secure Configuration &
Hardening Program, including full-disk encryption (FileVault), screen lock
after inactivity, Gatekeeper enabled, OS auto-updates enabled, and company-approved
software only.
12) Monitoring and Compliance
12.1) Access Logging
All access to production systems, databases, and Restricted data must be logged
with timestamp, user identity, action performed, and source IP. Logs are
centrally collected, protected from tampering, and retained for a minimum of
one (1) year. Privileged access logs are retained for seven (7) years.
12.2) Anomaly Detection and Alerting
Automated monitoring alerts on suspicious access patterns including logins from
new geographic locations, multiple failed authentication attempts, access
outside normal business hours (for non-operations roles), privileged access
usage, and bulk data export or download.
12.3) Compliance Audits
Security & Compliance conducts quarterly audits of access controls including
verification of approval documentation, validation of provisioning accuracy,
confirmation of timely revocation, and review of segregation of duties
compliance. Findings are documented and remediated within timeframes based on
severity (critical findings within seven (7) days, high within 30 days, medium
within 90 days).
13) Third-Party and Vendor Access
Access for third-party vendors, contractors, and consultants is governed by the
Vendor Risk Management Policy. Third-party access requires a documented
business need, contractual agreement with confidentiality and security
obligations, approval from Security & Compliance, time-limited access with
defined expiration, and dedicated credentials (no shared accounts with
workforce). Third-party access is reviewed monthly and revoked immediately upon
contract termination.
14) Roles and Responsibilities
14.1) Security & Compliance
- Owns and maintains this policy
- Approves high-risk and privileged access requests
- Conducts access reviews and compliance audits
- Monitors access logs and investigates anomalies
- Maintains documentation and metrics
14.2) Managers
- Submit access requests for team members
- Approve access requests within their authority
- Review team member access quarterly and annually
- Notify Security & Compliance of role changes and terminations
- Ensure team members understand access control requirements
14.3) System Owners and Administrators
- Provision and revoke access according to approved requests
- Maintain access control configurations following least privilege
- Document access changes and maintain audit trails
- Participate in access reviews for their systems
- Report access control issues to Security & Compliance
14.4) All Workforce Members
- Request only necessary access with business justification
- Protect credentials and authentication factors
- Report suspicious access or credential compromise immediately
- Comply with access restrictions and acceptable use requirements
- Complete security awareness training including access control topics
14.5) Human Resources
- Notify Security & Compliance of new hires, terminations, and role changes
- Coordinate onboarding and offboarding access procedures
- Maintain records of workforce status changes
15) Exceptions
Temporary exceptions to this policy require documented business justification,
explicit compensating controls, approval from Security & Compliance and the
Chief Information Security Officer (CISO) or designee, and a defined expiration
date not exceeding 90 days. Exceptions are tracked in the risk register and
reviewed weekly. Extensions require re-approval with updated justification.
Permanent exceptions require Board of Directors approval.
16) Training and Awareness
All workforce members complete access control training within 30 days of hire
covering requesting and using access appropriately, protecting credentials and
MFA factors, recognizing social engineering and phishing, reporting security
incidents, and understanding least privilege and need-to-know principles.
Annual refresher training is mandatory for all workforce members. Personnel
with privileged access receive additional training on privileged access
responsibilities, break-glass procedures, and logging requirements.
17) Documentation and Record Retention
All access-related documentation must be retained including access request and
approval records (seven years), provisioning and revocation logs (seven years),
access review certifications (seven years), exception approvals and risk
assessments (seven years), and training completion records (seven years).
Records are stored securely with restricted access and protected from
unauthorized modification.
18) Review and Maintenance
This policy is reviewed at least annually by Security & Compliance and approved
by the Chief Information Security Officer (CISO) or designee. Reviews are also
triggered by significant security incidents involving access control failures,
changes to regulatory requirements or industry standards, major changes to
systems or infrastructure, and audit findings or recommendations. Policy updates
are communicated to all workforce members within 30 days of approval.
19) Related Policies and Procedures
This policy should be read in conjunction with:
- Employment Screening and Acceptable Use Policy
- Information Classification & Handling Policy
- Secure Configuration & Hardening Program
- Vendor Risk Management Policy
- Incident Notification Procedure
- Change & Log Integrity Control
Appendix A — Standard Role Templates
Role: Software Engineer (Non-Senior)
- Google Workspace: Standard
- Slack: Standard
- Tailscale VPN: Standard
- Code repository: Read/write to assigned projects
- Development environment: Full access
- Staging environment: Read/write with peer review
- Production environment: No access (read-only with approval after 6 months)
- Database (dev/staging): Full access
- Database (production): No access
Role: Senior Software Engineer
- Inherits: Software Engineer permissions
- Production environment: Read access; write with peer review
- Database (production): Read-only with approval; write with dual approval
- CI/CD pipeline: Deployment approval authority
- Infrastructure: Read-only access
Role: Engineering Lead
- Inherits: Senior Software Engineer permissions
- Production environment: Full access with audit logging
- Database (production): Full access with audit logging
- Infrastructure: Administrative access with MFA
- Privileged access: Sudo on non-production; production with break-glass
- Access approval: Can approve production access for team
Role: Customer Support Specialist
- Google Workspace: Standard
- Slack: Standard
- Tailscale VPN: Standard
- Support ticketing system: Full access
- Customer data: Read-only with specific customer request ticket
- Production database: No direct access (queries via approved tooling only)
- Code repository: Read-only to documentation
Role: Finance/Operations
- Google Workspace: Standard
- Slack: Standard
- Financial systems: Role-appropriate access
- Customer data: Aggregated/anonymized reports only
- Production systems: No access
- Analytics platforms: Read-only
Appendix B — Access Request Template
Requestor Name: [Full name]
Requestor Email: [[email protected]]
Request Date: [YYYY-MM-DD]
Request Type: [New access / Modification / Temporary elevation]
Access Details:
- System/Application: [Specific system or application name]
- Access Level: [Read-only / Read-write / Administrative]
- Specific Permissions: [Detailed permissions or role]
Justification:
- Business Need: [Explain why access is required]
- Job Responsibilities: [How access relates to role]
- Duration: [Permanent / Temporary until YYYY-MM-DD]
Approvals:
- Manager: [Name] — [Approved/Denied] — [Date]
- Engineering Lead: [Name] — [Approved/Denied] — [Date] (if required)
- Security & Compliance: [Name] — [Approved/Denied] — [Date] (if required)
- Data Owner: [Name] — [Approved/Denied] — [Date] (if required)
Provisioning:
- Provisioned By: [Administrator name]
- Provisioning Date: [YYYY-MM-DD]
- Ticket Reference: [Ticket number or tracking ID]
Approved By:
Isa Hasenko
President and Founder
Electronically Signed By:
Isa Hasenko