Information
Security
Policy
Our commitment to identifying, mitigating, and monitoring information security risks across srvAudit LLC and all business operations.
Purpose & Scope
1.1 Purpose
This Information Security Policy establishes the framework for protecting the confidentiality, integrity, and availability of information assets owned, operated, and managed by srvAudit LLC and all of its doing-business-as (DBA) entities:
This policy defines the security controls, procedures, and responsibilities required to identify, mitigate, and continuously monitor information security risks relevant to our business operations, client data, and technology infrastructure.
1.2 Scope
- All information systems, networks, applications, and data under srvAudit LLC's operational control
- All employees, contractors, subcontractors, and third-party personnel who access company systems or data
- All environments including production, staging, development, and disaster recovery
- Cloud infrastructure (AWS), serverless compute (Lambda via Laravel Vapor), databases, storage, DNS, and email services
- Client data processed through proposals, contracts, payments, and service delivery
1.3 Regulatory & Contractual Context
srvAudit LLC aligns its security practices with applicable regulatory requirements and industry standards:
Information Security Organization
2.1 Information Security Officer (ISO)
The owner/principal of srvAudit LLC serves as the ISO with overall accountability for:
- › Establishing and maintaining this policy and supporting procedures
- › Conducting risk assessments and authorizing risk treatment plans
- › Ensuring compliance with applicable laws and contractual obligations
- › Reviewing and approving access to production systems
- › Leading incident response and breach notification activities
2.2 System Administrators / Developers
Personnel with privileged access are responsible for:
- › Implementing security controls as defined in this policy
- › Reporting security incidents or vulnerabilities immediately
- › Following secure development practices
- › Maintaining up-to-date systems and dependencies
2.3 Contractors & Third Parties
External personnel must:
- › Agree to confidentiality and acceptable use terms before accessing systems
- › Operate within the principle of least privilege
- › Return or destroy all company data upon engagement termination
Risk Management
3.1 Risk Identification
srvAudit LLC maintains an ongoing risk identification process:
3.2 Risk Assessment & Scoring
Identified risks are assessed using a qualitative risk matrix based on likelihood (rare → almost certain) and impact (negligible → critical). Risks scoring "high" or "critical" require documented treatment plans with assigned owners and deadlines.
3.3 Risk Treatment
Implement controls to reduce likelihood or impact to acceptable levels
Shift risk to a third party (cyber insurance, PCI-compliant processor)
Document residual risk when mitigation cost exceeds potential impact
Eliminate risk by discontinuing the activity or removing the asset
3.4 Risk Monitoring
- Automated alerts — AWS CloudWatch, GuardDuty, and application-level error monitoring
- Dependency audits — Automated Composer and npm vulnerability scanning in CI/CD pipelines
- Periodic review — Formal risk register review at least quarterly, or upon significant changes
- Log analysis — Review of access logs, authentication events, and anomalous activity
Access Control
4.1 Principles
4.2 Authentication
- Strong authentication required (minimum 12-character passwords or SSH key-based)
- MFA required for AWS root/IAM, Vapor, Stripe, domain registrars, and all critical SaaS
- Application-level TOTP available for all user accounts via Laravel Fortify 2FA
- API access uses scoped OAuth tokens (Sanctum / Passport) with appropriate expiration
- Non-human authentication via OAuth tokens, IAM roles, and TLS-encrypted service-to-service communication
4.3 Authorization
- Role-based access control (RBAC) with defined user roles and permission sets across all applications
- Centralized identity management: AWS IAM for infrastructure, Laravel Fortify for application-level authentication
- AWS IAM policies follow least-privilege with service-specific roles
- Direct production database access prohibited except for emergency maintenance
4.4 Access Reviews
- User access rights reviewed quarterly
- Systematic de-provisioning upon role change or termination — access revoked within 24 hours, shared credentials rotated immediately
- AWS IAM access keys and credentials rotated at least every 90 days
- Unused accounts disabled after 90 days of inactivity
4.5 Zero Trust Architecture
srvAudit LLC implements zero trust principles across its infrastructure:
- Serverless architecture (AWS Lambda) provides ephemeral, isolated execution environments with no persistent network access or standing credentials
- All service-to-service communication is authenticated and encrypted — no implicit trust based on network location
- AWS IAM roles enforce identity-based access policies; no shared or ambient credentials
- Application requests are authenticated and authorized individually regardless of source network
- Infrastructure access requires explicit identity verification (MFA + SSH keys) even from trusted networks
Data Protection
5.1 Data Classification
5.2 Encryption
5.3 Data Retention & Disposal
- Client data retained only for duration required by business relationship and legal obligations
- Secure deletion within 90 days of contract termination (unless legal hold)
- Backups follow 30-day retention; expired backups automatically purged
- Dev/staging environments use anonymized or synthetic data — no production client data
5.4 Payment Data
srvAudit LLC does not directly store, process, or transmit credit card numbers. All payment processing is delegated to Stripe (PCI DSS Level 1). Payment forms use Stripe Elements / Payment Intents, tokenizing card data client-side. We store only Stripe customer IDs, payment intent IDs, and transaction metadata.
Infrastructure Security
6.1 Cloud Architecture
Production applications deploy on AWS via Laravel Vapor (serverless Lambda), providing automatic patching, ephemeral execution environments, and AWS-managed infrastructure hardening.
6.2 Network Security
- Security Groups enforce strict ingress/egress (default deny, explicit allow)
- EC2 hardened: SSH key-only auth, non-default ports, automatic security updates
- CloudFront + AWS Shield Standard for DDoS mitigation and edge TLS
- VPC isolation for production resources not requiring direct internet access
6.3 Patch Management
- Vapor deployments inherit AWS-managed runtime patching
- EC2: automated unattended-upgrades (Ubuntu)
- Dependency monitoring via Composer audit and npm audit
6.4 Logging & Monitoring
- Application logs via Laravel logging subsystem
- AWS CloudTrail records all API activity
- CloudWatch alerting for anomalous infrastructure patterns
- Access logs (HTTP, SSH, database) retained minimum 90 days
Application Security
7.1 Secure Development Lifecycle
7.2 Dependency Management
- Third-party packages sourced from trusted registries (Packagist, npm)
- composer audit and npm audit run before each production deployment
- Lock files committed for reproducible builds
7.3 Secrets Management
- Secrets stored in environment variables — never in source code
- Production env vars managed via Vapor encrypted environments or AWS SSM SecureString
- Regular rotation schedule; immediate rotation upon suspected compromise
Incident Response
8.1 Incident Classification
8.2 Response Procedures
Identify incident, assess severity, assign incident lead
Isolate affected systems — revoke access, disable accounts, block IPs
Remove root cause — patch vulnerability, remove malware, rotate credentials
Restore from verified clean backups; validate integrity before production return
Document lessons learned, update controls and risk register within 14 days
8.3 Breach Notification
Per A.R.S. § 18-552, affected individuals are notified within 45 days of breach discovery. Breaches affecting 1,000+ individuals trigger Arizona Attorney General notification. Clients receive direct email with breach details, data involved, and recommended protective actions.
8.4 Communication
- All incident communications coordinated through the ISO
- External communications require ISO approval
- Incident details shared internally on need-to-know basis only
Business Continuity & Disaster Recovery
9.1 Backups
- RDS automated daily snapshots with 30-day retention
- S3 bucket versioning and cross-region replication for critical data
- Backup restoration tested at least semi-annually
9.2 Availability
- Lambda/Vapor: automatic scaling and multi-AZ high availability
- CloudFront CDN: global edge availability, regional outage mitigation
- RDS Multi-AZ deployments for database failover
9.3 Recovery Objectives
Third-Party & Vendor Management
10.1 Key Vendors
10.2 Ongoing Monitoring
- Critical vendor certifications verified annually
- Vendor access reviewed as part of quarterly access reviews
- Vendor security incidents monitored via public advisories
Personnel Security
11.1 Onboarding
- All personnel acknowledge this policy before receiving credentials
- Access provisioned based on role with least-privilege defaults
- Contractors sign confidentiality/NDA covering data handling
11.2 Security Awareness
- Briefings on phishing, social engineering, and credential handling
- Security best practices documented and accessible
- Emerging threats communicated promptly
11.3 Offboarding
- Access revoked within 24 hours of engagement termination
- Company equipment and data returned or confirmed destroyed
- Shared credentials rotated immediately upon privileged user departure
Compliance & Audit
12.1 Internal Audits
- Security controls audited internally at least annually
- Scope: access controls, encryption, logging, backup integrity, incident response
- Findings documented with remediation timelines and tracked to closure
12.2 External Assessments
- Third-party pen testing as required by contracts or risk profile
- Results reviewed by ISO and remediated per risk treatment framework
12.3 Recordkeeping
- Policies, risk assessments, incident reports, and audit findings retained 3+ years
- Records stored securely, accessible only to authorized personnel
Policy Governance
13.1 Review Cycle
This policy is reviewed and updated at least annually, or upon:
- Significant changes to operations, technology, or threat landscape
- A security incident revealing policy gaps
- Changes in applicable laws or regulations
- Client or contractual requirements
13.2 Approval
This policy is approved and authorized by the principal of srvAudit LLC in their capacity as Information Security Officer.
13.3 Version History
| Version | Date | Description |
|---|---|---|
| 1.0 | March 10, 2026 | Initial policy creation and publication |
Questions or Security Concerns
For questions about this policy, to report a security concern, or to request a copy of our risk register:
[email protected]