TaxPinTaxPin

ARKITEKTURA NG SEGURIDAD

Ang seguridad ay ang arkitektura, hindi isang feature

Ang sistemang humahawak ng datos ng mga nagbabayad ng buwis ay hindi puwedeng umasa lang sa “pag-iingat.” Ipinapatupad ang mga proteksyon ng TaxPin sa database layer, hindi sa application code — hindi ito mga opsyong puwedeng i-off, kundi istrukturang hindi malulusutan.

EncryptionHiwalay bawat opisinaTwo-factor authenticationMga audit logPagsunod sa regulasyon

Mga pangunahing proteksyon

🔐

Naka-encrypt habang ipinapadala at nakaimbak

Bawat dokumento ay dumadaan sa TLS at iniimbak gamit ang AES-256 encryption (ang mga key ay pinamamahalaan ng infrastructure provider). Parehong naka-encrypt habang nakaimbak ang database at storage, at kinokontrol ang access sa mga file ng row-level security bawat opisina at ng mga signed link na nag-e-expire.

🤖

AI at sensitibong datos

Ang mga form tulad ng W-2, 1099 at ID ay binabasa gamit ang AWS Textract. Direktang ipinapadala ang file para iproseso at hindi iniimbak sa aming AWS account, at naka-opt-out ang AWS account na iyon para hindi gamitin ng AWS ang nilalaman ng mga kliyente sa pagbuo o pagpapabuti ng mga AI service nito. Kapag may ipinapadalang teksto sa Claude (Anthropic API) para sa pagbasa ng statement, pagbasa ng abiso o pagbuo ng draft, buong tinatakpan ang SSN at pinaiikli sa huling apat na digit ang mahahabang account number. Ang mga SSN at TIN na nabasa mula sa dokumento ay tinatatakan ng AES-256-GCM, nakatakip lang kapag ipinapakita, at buong ipinapakita lang pagkatapos ng two-step verification, may audit record.

🪪

Pagpapatunay ng pagkakakilanlan sa remote na pirma (KBA)

Kapag binuksan lamang ng opisina ang pagpapatunay ng pagkakakilanlan (KBA) para sa remote na pirma sa Form 8879, magbubukas ang window ng provider naming BoldSign. Sasagot doon ang kliyente ng mga tanong na batay sa kanyang credit record at pipirma; natatanggap ng BoldSign ang pangalan sa Ingles at email ng pipirma at ang dokumentong pipirmahan. Hindi dumadaan sa mga server ng TaxPin ang mga sagot, at resulta lamang (pasado o hindi) at ang talaan ng pagpapatunay ang itinatago namin. Pagkatapos ng 3 bigong subok, lilipat ang pirma sa personal na pagbisita sa opisina o sa papel.

🧼

Paglilinis ng in-upload na file at virus scan

Ang mga litrato at PDF na in-upload ng kliyente ay muling sine-save ng server bilang bagong file. Natatanggal sa litrato ang lokasyon at impormasyon ng device; natatanggal sa PDF ang JavaScript, attachment at mga aksyong tumatakbo kapag binuksan. Kung iba ang itsura ng nilinis na resulta sa orihinal, pinananatili ang orihinal. Pagkatapos, lahat ng file (kasama ang ipinadala ng opisina) ay ini-scan para sa virus gamit ang AWS GuardDuty, at ang file na ipinadala ng opisina ay makikita lamang ng kliyente kapag tapos na ang scan. Kapag may nakitang banta, iku-quarantine ang file, isang pahina ng abiso lamang ang maiiwan, at aabisuhan ang opisina.

🏢

Ganap na paghihiwalay ng mga opisina (RLS)

Ang multi-tenant isolation ay ipinapatupad ng PostgreSQL Row-Level Security, hindi ng application code. Bawat query sa bawat table ay limitado sa opisina, kaya hindi talaga ibinabalik ang datos ng ibang opisina. Hindi lang pagbasa: ang pagsulat (INSERT/UPDATE) ay nakatali rin sa ugnayan ng opisina↔kliyente.

⏱

Mga signed link na nag-e-expire

Walang permanenteng pampublikong URL. Bawat pagtingin at pag-download ay dumadaan sa signed link na mag-e-expire sa loob ng ilang minuto, at bine-verify ang storage path sa parehong bahagi ng opisina at ng kliyente.

📱

Two-factor authentication (MFA · aal2)

Magagamit ng mga tax preparer at ng mga kliyente ang MFA gamit ang authenticator app. Ang mahalaga ay ang database, hindi ang UI — kapag may naka-enroll nang factor, hinihingi ng database ang aal2 session, kaya hindi maaabot ng password lang ang anumang datos.

📜

Audit log na hindi mababago

Awtomatikong naitatala ang mga upload, download, pagbura, pagbabago sa profile, pagbabago sa team, pagbabago sa pahintulot (consent), at mga internal note. Append-only ang log at hindi ito mae-edit o mabubura ng application.

🚪

Awtomatikong pag-sign out

Natatapos ang session pagkatapos ng 30 minutong walang aktibidad, kaya walang naiiwang bukas sa shared o pampublikong computer.

📎

Walang dokumento sa email

Hindi kailanman may attachment ang mga notification email — “tingnan ang iyong portal” lang. Kahit ma-compromise ang inbox, walang dokumentong malalantad.

🛡

Mga transport security header

Naka-apply sa bawat route ang Content-Security-Policy, HSTS, X-Frame-Options (proteksyon laban sa clickjacking), at nosniff. Ang mga lihim na para lang sa server (service key, SMTP, SMS token) ay hindi kailanman ipinapadala sa browser.

Ang dinadaanan ng isang dokumento

1

Upload

Kinukunan ng litrato ng kliyente; ipinapadala ito ng browser sa TLS. Bine-validate ang uri at laki ng file (25MB), at itinatali ang storage path sa kliyente at opisinang iyon.

2

Naka-encrypt na storage

Iniimbak gamit ang AES-256. Walang pampublikong URL na nagagawa kailanman.

3

Abiso

Nakakatanggap ang preparer ng alert na “bagong dokumento” — walang attachment, link lang sa portal.

4

Access

Mga awtorisadong user lang ang makakapagbukas nito gamit ang signed link na nag-e-expire sa loob ng ilang minuto. Naitatala sa audit log ang mga pagtingin at pag-download.

5

Pagbura

Kapag binura, mawawala ito sa magkabilang panig, at naitatala rin sa audit log ang mismong pagbura.

Sino ang makakakita ng ano

Mga preparer (miyembro ng opisina)Mga kliyente, dokumento, at request lang ng sarili nilang opisina. Walang access sa datos ng ibang opisina. Ang may-ari (owner) lang ang nakakapamahala ng team.
Mga kliyente (nagbabayad ng buwis)Sarili lang nilang mga dokumento, request, at profile. Hindi nila makikita ang ibang kliyente sa parehong opisina.
Mga internal notePara sa preparer lang. Nakahiwalay sa sariling table at hindi kailanman ipinapakita sa mga kliyente.
Platform (TaxPin)Ang mga operational na function gaya ng paggawa ng opisina at pag-apruba ng trial ay nakahiwalay sa likod ng hiwalay na admin role. Walang access ang mga ordinaryong account.

Pagsunod sa regulasyon

Paano tumutugma ang TaxPin sa mga kontrol na hinihingi ng mga regulasyon ng U.S. sa datos ng buwis.

✓ IRS Publication 4557

Ang gabay ng IRS para sa mga tax pro tungkol sa pagprotekta ng datos ng nagbabayad ng buwis. Sinusuportahan ng sistema ang mga pangunahing requirement nito: encryption, multi-factor authentication, access control, awtomatikong lock-out, at pag-log ng access.

✓ FTC Safeguards Rule (16 CFR Part 314)

Hinihingi nito ang access control, encryption, multi-factor authentication, pagmo-monitor ng aktibidad, at change management — natutugunan sa pamamagitan ng RLS access control, encryption habang ipinapadala/nakaimbak, MFA, at mga audit log.

✓ GLBA Privacy Notice

Kasama sa aming Privacy Policy ang GLBA privacy notice.

✓ Suporta sa WISP

Sinasaklaw ng TaxPin ang mga teknikal na kontrol ng Written Information Security Plan (WISP) ng opisina (encryption, access control, MFA, logging), para matulungan ang iyong opisina na buuin ang plano nito.

Tapat na hangganan — shared responsibility

InfrastructureTumatakbo ang TaxPin sa cloud infrastructure na may SOC 2 (managed database at deployment platform). Ang pisikal na seguridad, networking, at availability ay sumusunod sa mga sertipikadong kontrol ng mga provider na iyon.
Pag-verify ng seguridadPinagsasama namin ang mga internal adversarial review at isang external assessment (WebEASM AEGISonar). Tingnan ang mga pahinang “Internal Security Audit” at “External Security Audit” sa ilalim ng Resources para sa pamamaraan, saklaw, at mga scenario.
Ang iyong bahagiAng pag-enroll ng MFA, paggamit ng matitibay na password, at maingat na paghawak ng mga link (pagbabahagi ng invite/request link sa mga pinagkakatiwalaang tao lang) ay responsibilidad ng opisina at ng kliyente. Sinusuportahan ito ng sistema pero hindi nito kayang palitan.

Kung may tanong ka tungkol sa seguridad o kailangan mo ng mga materyales para sa due diligence, makipag-ugnayan sa amin anumang oras.