MyFincaLink Technical Security Annex

Technical summary for property-management firms, clients and audits. It describes implemented application controls and procedures that depend on each deployment’s operation.

1. Architecture and information separation

MyFincaLink uses a multi-firm, multi-community architecture. Each community’s operational information remains within its data scope, and the application validates the authorised context before resolving connections or performing operations.

2. Database access control

Connections are resolved server-side and are not exposed to the browser. Processes use function-specific credentials, prepared statements and role- and module-based permissions.

3. Protection of credentials and sensitive data

Passwords are stored using suitable hashes, never as plain text. Implemented sensitive fields use authenticated encryption and non-reversible cryptographic indexes where searches are required. Keys remain separate. Documents are encrypted and verified with SHA-256 during migrations.

4. Secure HTTPS/TLS communications

The public deployment must use HTTPS/TLS and valid certificates. The application generates secure-context URLs and applies defensive headers; certificate configuration and renewal belong to the deployment infrastructure.

5. Server security

Configuration files, connections and operational scripts are protected from web access. Maintenance runs outside the public flow, and errors are logged without exposing internal details to end users.

6. Application backups

Recovery includes versioned code, declared dependencies and required external configuration. Secrets, logs, private documents and backups are excluded from public code packages.

7. Database backups

Service operation provides for copies of the central and operational databases. Frequency, retention and encryption must be defined and monitored for each deployment according to risk.

8. External backup storage

Operational copies should be kept outside the primary infrastructure. Storage migrations require a backup path outside the web directory and retain originals and copies until review.

9. Verification and restoration tests

Document migrations create a manifest, verify integrity with SHA-256 and update references only after the batch is verified. Database and application restorations should be tested periodically in a controlled environment.

10. Backup automation and monitoring

Scheduled jobs record status, progress, verified items, failures and the latest error. Automation does not replace result review or recovery testing.

11. Security updates

Code, dependencies and the host system should be reviewed periodically. Fixes are tested before deployment and schema migrations use versioned scripts.

12. Security by design

Authorisation, client separation, encryption, input validation, output escaping and traceability are part of the design of features that process private information.

13. Review and continuous improvement

Controls are reviewed as the platform evolves. Measures depending on the server, storage provider or operating policy must be verified and documented for the specific deployment.