Data and access safety

Data Handling and Access Safety

Plain-language notes on how StackRefit handles access, credentials, client data, production safety, NDA/DPA expectations, and AI-assisted work.

Start an audit → View access checklist

Principles

Practical safeguards for legacy-system work.

StackRefit works on systems that may run bookings, orders, operations, customer portals, admin workflows, or revenue-critical websites. Access has to be handled carefully.

Ask only for access needed for the agreed scope.
Prefer read-only access for audits.
Use least-privilege access wherever possible.
Avoid shared accounts when temporary named accounts can be created.
Do not request passwords through the contact form.
Do not ask for raw customer data without clear reason and written approval.
Do not make production changes without written scope and approval.
Check backup and rollback expectations before risky work.
Use NDA and DPA documents where appropriate.
Do not process client code, logs, credentials, or personal data through external AI tools without explicit written permission.
Revoke access after the engagement or when access is no longer needed.

Review surfaces

What StackRefit may review.

Area	Examples
Application code	PHP, Laravel, WordPress themes/plugins, WooCommerce customizations, Symfony, CodeIgniter, custom modules.
Dependency files	composer.json, composer.lock, package.json, lockfiles, plugin lists, framework versions.
Hosting/server setup	Linux version, PHP runtime, web server, database version, control panel, cron jobs, queues.
CMS/admin configuration	WordPress/WooCommerce settings, plugin state, user roles, update posture, critical configuration.
Database metadata	Engine/version, schema overview, table structure, migrations, size, backup approach.
Deployment process	Repository, staging, CI/CD, manual deploy process, rollback notes, release habits.
Logs and monitoring	Error visibility, uptime monitoring, application logs, hosting logs, alerting tools.
Documentation	README files, handover notes, hosting notes, runbooks, client instructions.
Integrations	Payment, email, CRM, booking, analytics, webhooks, APIs, search, automation tools.

What not to send through the contact form

Please do not paste or upload passwords, SSH keys, API keys, .env files, source code, screenshots containing sensitive data, database dumps, customer exports, production logs, payment details, private client documents, or personal data that is not needed for scoping.

Credentials and access

Temporary, named, least-privilege access.

Avoid shared admin accounts where possible. If a shared account is unavoidable, confirm who owns it, why it is being used, and when access will be rotated or revoked.

Preferred access

Temporary named accounts, role-based access, read-only audit access, password-manager sharing, key-based SSH, 2FA where supported, and documented revocation.

SSH and server access

Unrestricted root access is usually unnecessary for audits. Broader access may be needed for upgrade or rescue work, but production changes still need approval and rollback thinking.

Database access

Schema-only export, read-only database user, hosting dashboard metadata, guided walkthrough, redacted examples, or sanitized staging database are preferred over production dumps.

AI-assisted work

AI-assisted, not AI-hyped.

AI tools may help with internal structure, checklists, note organization, documentation drafting, risk classification, and sanitized technical analysis.

StackRefit does not send client code, logs, credentials, personal data, customer data, or confidential system details to external AI tools without explicit written permission.

If AI processing is useful for a specific engagement, the scope should clarify what data may be processed, what is excluded, whether redaction is required, which providers are allowed, and whether the client or agency has internal AI policies.

Production changes

Audits are read-only by default.

Urgent fixes still need approval. Speed is useful, but uncontrolled production access creates avoidable risk.

Written scope
Named approver
Backup confirmation
Rollback plan where feasible
Staging-first approach where practical
Maintenance window if needed
Clear communication channel
Post-change notes
Known assumptions and limitations

Backups and rollback

Backups are not just a checkbox.

Do backups include files and database?

Where are backups stored?

Who controls the backup account?

When was the last successful backup?

Has restore been tested?

How long would restore take?

Is there a staging copy?

Can changes be rolled back through Git, snapshots, database restore, or deployment tooling?

NDA, DPA, and confidentiality

Plain-language operating summary, not legal terms.

Contractual terms should be agreed in the relevant proposal, SOW, NDA, or DPA.

NDA before sensitive access

DPA where personal data processing is involved

Written statement of work

White-label agency arrangement

Client-approved named specialist arrangement

Internal-only technical review

White-label agency work

Protect the agency relationship.

For white-label work, the agency remains the client-facing owner unless agreed otherwise. StackRefit does not contact the end client without approval.

Reports can be prepared for agency use or adapted for client presentation.
Client names and system details are treated as confidential.
Case studies are not published without permission.
Access and approvals should be clear before production work.
Agency relationship and client communication stay controlled.

Logs and evidence

Useful evidence can expose sensitive information.

When sharing logs or screenshots, redact email addresses, tokens, customer names, order IDs, session identifiers, private URLs, payment details, authentication screens, and account-management screens where possible.

Retention and access removal

Access should be removed or reduced after the engagement.

Revoke temporary CMS/admin accounts.
Revoke SSH users or deploy keys no longer needed.
Remove repository access no longer needed.
Rotate shared credentials if they were used.
Confirm ongoing Care access separately.
Avoid storing credentials inside reports, tickets, or shared documents.

Critical findings

If StackRefit finds a critical issue.

Document the issue clearly.

Notify the agreed agency or client contact.

Avoid public disclosure.

Avoid unilateral production changes unless emergency authority has been agreed.

Recommend a contained next step.

Separate immediate risk reduction from broader modernization work.

Safer access starts before the audit.

Most legacy-system risk is ordinary operational uncertainty: old versions, unclear ownership, missing documentation, untested backups, manual deploys, and people relying on memory.

Start an audit → View access checklist