Log File Security Guide
Version: 1.0
Audience: Automize Clients, Administrators, IT Security Teams
Purpose: To ensure that all log files are created, stored, accessed, and retained securely.
1. Introduction
The Automize platform generates logs during bot execution, system activity, and error handling. These logs are essential for:
- Troubleshooting
- Auditing and compliance
- Process optimisation
However, logs may contain sensitive information such as:
- Usernames or email addresses
- System metadata
- Process inputs or extracted values
- Application window titles
This guide outlines how to protect Automize log data from unauthorised access or misuse.
2. Types of Logs Generated by Automize
Automize creates the following log categories:
| Log Type | Description | Location |
|---|---|---|
| Execution Logs | Records each step the bot performs, statuses, timing, output values. | Stored locally on the bot host. |
| Error / Exception Logs | Detailed breakdown of failures and exception stack traces. | Stored locally and mirrored to the portal. |
| Debug Logs | Higher-detail logs for development or testing. | Developer machine only. |
| Activity Snapshots | Screenshots or UI context for troubleshooting (optional). | Stored safely on encrypted storage. |
Each log type may contain sensitive content and must be secured accordingly.
3. Log File Locations & Access Controls
3.1 Bot Machine Log Storage
By default, Automize stores logs in a protected directory on the Windows host running the bot. Only authorised users with elevated permissions (e.g., IT administrators) may access this folder.
Recommended Access Rules:
- Restrict access to specific Windows user groups (e.g., Administrators).
- Disable inheritance from parent folders.
- Ensure logs are stored on encrypted local drives (BitLocker recommended).
- Ensure the bot service account does not have permission to read other bots' logs.
3.2 Web Portal Log Access
Only authenticated users with the appropriate Automize role may view logs within the Web Portal. Access is controlled using:
- Role-based permissions (Admin, Developer, Viewer)
- Audit history of who opened or downloaded logs
- Secure HTTPS transport for all log transfers
3.3 API Access
If log data is accessed via API, clients must ensure:
- API keys are stored securely
- No API tokens are embedded in code repositories
- Outbound API requests are limited to authorised servers only
4. Log File Encryption & Transmission
4.1 Data at Rest
Automize recommends enabling system-level encryption for all local log directories. Options include:
- Windows BitLocker (recommended)
- Encrypted network shares for central storage
4.2 Data in Transit
All communication between bot, portal, and Automize cloud services is transmitted over:
- HTTPS (TLS 1.2+)
- Secure WebSocket channels where applicable
No logs are sent unencrypted under any circumstances.
5. Sensitive Information Handling
5.1 Avoid Logging Personal or Confidential Data
Clients are advised to design processes that avoid writing sensitive values directly into logs.
Examples of data that should NOT be logged:
- Passwords or authentication tokens
- Credit card or banking details
- ID numbers or personal health information
- Customer account numbers
5.2 Masking Sensitive Data
Where logs include sensitive values, Automize automatically masks common fields such as passwords and token values. Clients may implement additional masking via:
- Custom variable names
- Encrypted activity output
- Manual sanitisation in the workflow
6. Retention & Purging Policy
6.1 Recommended Log Retention Settings
Clients should define a policy based on internal compliance requirements.
| Log Type | Recommended Retention |
|---|---|
| Debug Logs | 7–14 days |
| Execution Logs | 30–90 days |
| Error Logs | 90–180 days |
| Audit Logs | 1–3 years (depending on compliance) |
6.2 Automated Purging
Clients should configure scheduled tasks or scripts to automatically remove logs older than the retention period.
Purging must:
- Use secure deletion where possible
- Be verified regularly
- Be documented for audit purposes
7. Backup, Restore & Disaster Recovery
7.1 Log Backups
Execution logs may be required for post-incident analysis. When backing them up:
- Ensure encrypted backup storage
- Restrict backup archive access
- Document the restore process
7.2 Disaster Recovery
Critical logs should be included in the client DR plan. This includes:
- Error logs for RCA (Root Cause Analysis)
- Audit records
- Bot crash logs
8. Monitoring & Audit Trails
The Automize platform maintains a secure, immutable audit trail of:
- User login attempts
- Process executions
- Log file downloads or modifications
- API key usage
Clients should review audit logs regularly to detect:
- Suspicious access attempts
- Unexpected bot behaviour
- Access from unauthorised locations
9. Responsibilities
9.1 Automize Responsibilities
- Secure encryption for all cloud-hosted logs
- Role-based access controls on the portal
- Automatic masking of sensitive fields
- Secure transmission of all system events
9.2 Client Responsibilities
- Implement local file security on bot machines
- Limit log access to authorised personnel
- Apply internal retention and deletion policies
- Ensure bots do not capture unnecessary sensitive data
- Provide secure network environments for bot execution
10. Summary
By following this guide, clients can ensure that all Automize log files remain protected, compliant, and accessible only to authorised personnel. Proper log security reduces operational risk, prevents data exposure, and supports a reliable automation environment.
If you need assistance implementing any of these log security recommendations, please contact your Automize support team.